From: PG Bug reporting form <noreply@postgresql.org>
To: pgsql-bugs@lists.postgresql.org
Cc: ocean_li_996@163.com
Subject: BUG #18150: The results returned by index only scan using gist index of bpchar and seqscan have difference.
Date: Sun, 08 Oct 2023 15:52:05 +0000
Message-ID: <18150-b3922f47e62d4d12@postgresql.org> (raw)
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!
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: noreply@postgresql.org, pgsql-bugs@lists.postgresql.org, ocean_li_996@163.com
Subject: Re: BUG #18150: The results returned by index only scan using gist index of bpchar and seqscan have difference.
In-Reply-To: <18150-b3922f47e62d4d12@postgresql.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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