Re: [HACKERS] Custom compression methods

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: [HACKERS] Custom compression methods
Дата
Msg-id CAFiTN-uiW_vJjObr6DYQZHb33Zt+azQvXXZOAgrMMODn4KB9jg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Custom compression methods  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Ответы Re: [HACKERS] Custom compression methods  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Список pgsql-hackers
On Sat, Mar 20, 2021 at 3:05 PM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
>
> 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];

Ok, I was not aware of this.

> 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).

Okay

> 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.

Right, I think for now we can use default compression for this case.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



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

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