Thread: BUG #18150: The results returned by index only scan using gist index of bpchar and seqscan have difference.

The following bug has been logged on the website:

Bug reference:      18150
Logged by:          ocean li
Email address:      ocean_li_996@163.com
PostgreSQL version: 11.9
Operating system:   centos7 5.10.84 x86_64
Description:

When testing consistency between index (only) scan and seqscan, I found that
the results returned by index only scan using gist index of bpchar and
seqscan have difference.
A case given below can reproduce the scene:

-- preparation 
* create extension btree_gist;
* create table t1(f_char char(32));
* create index on t1 using gist (f_char);
* insert into t1 select i from generate_series(1,10000)i;

-- test
* set enable_bitmapscan to off;
* explain analyze select * from t1 where f_char = '1';
                                                        QUERY PLAN

---------------------------------------------------------------------------------------------------------------------------
 Index Only Scan using t1_f_char_idx on t1  (cost=0.15..80.51 rows=21
width=132) (actual time=0.424..0.426 rows=1 loops=1)
   Index Cond: (f_char = '1'::bpchar)
   Heap Fetches: 1
 Planning Time: 0.102 ms
 Execution Time: 0.477 ms
(5 rows)

* select * from t1 where f_char = '1';
 f_char
--------
 1
(1 row)

* set enable_indexscan to off;
* set enable_indexonlyscan to off;
* explain analyze select * from t1 where f_char = '1';
                                          QUERY PLAN
-----------------------------------------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..209.00 rows=1 width=33) (actual
time=0.016..2.336 rows=1 loops=1)
   Filter: (f_char = '1'::bpchar)
   Rows Removed by Filter: 9999
 Planning Time: 0.076 ms
 Execution Time: 2.367 ms
(5 rows)

* select * from t1 where f_char = '1';
              f_char
----------------------------------
 1
(1 row)

Obviously, the last paddings of index only scan return are cut. But the last
paddings of seqscan return are not cut. Actually, the difference exists in
gist index leaf key and table metadata. And I think it is caused by the
behavior of *gbt_bpchar_compress* function. Related  code are:
* ...
* if (entry->leafkey)
*    {
*
*        Datum        d = DirectFunctionCall1(rtrim1, entry->key);
* ...

I don't know whether the scene is a bug or an expected behavior. In my
opinion, it may be a bug. So it reported here. 

Best regards!

PG Bug reporting form <noreply@postgresql.org> writes:
> PostgreSQL version: 11.9

> When testing consistency between index (only) scan and seqscan, I found that
> the results returned by index only scan using gist index of bpchar and
> seqscan have difference.

This was fixed last year, in 11.15 (and releases of same date in other
branches).  Per those release notes:

  Fix results of index-only scans on contrib/btree_gist indexes on char(N)
  columns (Tom Lane)

    Index-only scans returned column values with trailing spaces removed,
    which is not the expected behavior. That happened because that's how
    the data was stored in the index. This fix changes the code to store
    char(N) values with the expected amount of space padding. The behavior
    of such an index will not change immediately unless you REINDEX it;
    otherwise space-stripped values will be gradually replaced over time
    during updates. Queries that do not use index-only scan plans will be
    unaffected in any case.


            regards, tom lane