pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
BUG #18150: The results returned by index only scan using gist index of bpchar and seqscan have difference.
2+ messages / 2 participants
[nested] [flat]

* BUG #18150: The results returned by index only scan using gist index of bpchar and seqscan have difference.
@ 2023-10-08 15:52  PG Bug reporting form <noreply@postgresql.org>
  0 siblings, 1 reply; 2+ messages in thread

From: PG Bug reporting form @ 2023-10-08 15:52 UTC (permalink / raw)
  To: pgsql-bugs@lists.postgresql.org; +Cc: ocean_li_996@163.com

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!



^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* Re: BUG #18150: The results returned by index only scan using gist index of bpchar and seqscan have difference.
@ 2023-10-08 16:17  Tom Lane <tgl@sss.pgh.pa.us>
  parent: PG Bug reporting form <noreply@postgresql.org>
  0 siblings, 0 replies; 2+ messages in thread

From: Tom Lane @ 2023-10-08 16:17 UTC (permalink / raw)
  To: ocean_li_996@163.com; +Cc: pgsql-bugs@lists.postgresql.org

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





^ permalink  raw  reply  [nested|flat] 2+ messages in thread


end of thread, other threads:[~2023-10-08 16:17 UTC | newest]

Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-10-08 15:52 BUG #18150: The results returned by index only scan using gist index of bpchar and seqscan have difference. PG Bug reporting form <noreply@postgresql.org>
2023-10-08 16:17 ` Tom Lane <tgl@sss.pgh.pa.us>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox