Re: Index-only scan for btree_gist turns bpchar to char
От | Tom Lane |
---|---|
Тема | Re: Index-only scan for btree_gist turns bpchar to char |
Дата | |
Msg-id | 4053318.1641323961@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Index-only scan for btree_gist turns bpchar to char (Alexander Lakhin <exclusion@gmail.com>) |
Ответы |
Re: Index-only scan for btree_gist turns bpchar to char
Re: Index-only scan for btree_gist turns bpchar to char |
Список | pgsql-hackers |
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 also wondered if we could make the fetch function reconstruct the padding, but it doesn't seem to have access to the necessary info. regards, tom lane
В списке pgsql-hackers по дате отправления: