Re: Index-only scan for btree_gist turns bpchar to char

Поиск
Список
Период
Сортировка
От Alexander Lakhin
Тема Re: Index-only scan for btree_gist turns bpchar to char
Дата
Msg-id 9e09d032-298e-d57d-31a0-7984981851d9@gmail.com
обсуждение исходный текст
Ответ на Re: Index-only scan for btree_gist turns bpchar to char  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
04.01.2022 22:19, Tom Lane wrote:
> Alexander Lakhin <exclusion@gmail.com> writes:
>> While testing the index-only scan fix, I've discovered that replacing
>> the index-only scan with the index scan changes contrib/btree_gist
>> output because index-only scan for btree_gist returns a string without
>> padding.
> Ugh, yeah.  This seems to be because gbt_bpchar_compress() strips
> trailing spaces (using rtrim1) before storing the value.  The
> idea evidently is to simplify gbt_bpchar_consistent, but it's not
> acceptable if the opclass is supposed to support index-only scan.
>
> I see two ways to fix this:
>
> * Disallow index-only scan, by removing the fetch function for this
> opclass.  This'd require a module version bump, so people wouldn't
> get that fix automatically.
>
> * Change gbt_bpchar_compress to not trim spaces (it becomes just
> like gbt_text_compress), and adapt gbt_bpchar_consistent to cope.
> This does nothing for the problem immediately, unless you REINDEX
> affected indexes --- but over time an index's entries would get
> replaced with untrimmed versions.
I think that the second way is preferable in the long run. It doesn't
need an explanation after years, why index-only scan is not supported
for that type. One-time mentioning the change and the need for REINDEX
in release notes seems more future-oriented to me.

Best regards,
Alexander



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

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Emit "checkpoint skipped because system is idle" message at LOG level if log_checkpoints is set
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_stat_statements and "IN" conditions