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

  1. Fix results of index-only scans on btree_gist char(N) indexes.