Re: Index-only scan for btree_gist turns bpchar to char
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-01-04T19:19:21Z
Lists: 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
Commits
-
Fix results of index-only scans on btree_gist char(N) indexes.
- b2198690847f 10.20 landed
- 823d4c7e2538 13.6 landed
- 54b1cb7eb784 15.0 landed
- 3a69d45afcc8 12.10 landed
- 38cbdd22d633 11.15 landed
- 043c1e1a73aa 14.2 landed