Re: [HACKERS] Custom compression methods

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: [HACKERS] Custom compression methods
Дата
Msg-id e0367f27-392c-321a-7411-a58e1a7e4817@enterprisedb.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Custom compression methods  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Custom compression methods  (Dilip Kumar <dilipbalaut@gmail.com>)
Список pgsql-hackers
Hi,

I think this bit in brin_tuple.c is wrong:

    ...
    Form_pg_attribute att = TupleDescAttr(brdesc->bd_tupdesc,
                                          keyno);
    Datum       cvalue = toast_compress_datum(value,
                                              att->attcompression);

The problem is that this is looking at the index descriptor (i.e. what
types are indexed) instead of the stored type. For BRIN those may be
only loosely related, which is why the code does this a couple lines above:

    /* We must look at the stored type, not at the index descriptor. */
    TypeCacheEntry *atttype
        = brdesc->bd_info[keyno]->oi_typcache[datumno];

For the built-in BRIN opclasses this happens to work, because e.g.
minmax stores two values of the original type. But it may not work for
other out-of-core opclasses, and it certainly doesn't work for the new
BRIN opclasses (bloom and minmax-multi).

Unfortunately, the only thing we have here is the type OID, so I guess
the only option is using GetDefaultToastCompression(). Perhaps we might
include that into BrinOpcInfo too, in the future.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Markus Wanner
Дата:
Сообщение: Re: Logical Replication vs. 2PC
Следующее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: Columns correlation and adaptive query optimization