| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> |
| Cc: | 王跃林 <violin0613(at)tju(dot)edu(dot)cn>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, 3764353996 <3764353996(at)qq(dot)com> |
| Subject: | Re: Fw:Re: Fw: gbt_var_consistent in contrib/btree_gist/btree_utils_var.c has internal-node type confusion on the <> strategy, bypassing exclusion constraints |
| Date: | 2026-07-03 17:01:19 |
| Message-ID: | 3879867.1783098079@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
For the archives' sake: I tested the 0003 patch (sort with bitcmp
not byteacmp) with the attached script. I get this with HEAD:
-> Index Only Scan using varbitidx on varbittmp (cost=0.28..219.00 rows=3584 width=0) (actual time=0.146..1.895 rows=3200.00 loops=1)
Index Cond: (a > '11111'::bit varying)
Heap Fetches: 0
Index Searches: 1
Buffers: shared hit=1 read=110
and this with the bitcmp patch:
-> Index Only Scan using varbitidx on varbittmp (cost=0.28..267.00 rows=3584 width=0) (actual time=0.081..0.955 rows=3200.00 loops=1)
Index Cond: (a > '11111'::bit varying)
Heap Fetches: 0
Index Searches: 1
Buffers: shared hit=1 read=47
You might get different hit-vs-read splits depending on your
shared_buffers setting, but the totals should be pretty stable.
So that's a clear win, and indeed running the same script on
v17 shows 50-some buffer accesses, so we did lose performance
from this mistake.
I don't see any win however for a bit(N) column where all the
entries are the same width. This is unsurprising, since the
bit_len prefix is the same for all and so the bytea sort gives
the same ordering as bitcmp. Possibly this explains our failure
to notice this problem earlier.
Anyway, 0003 seems quite solid so I'll go push that part.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| btree-gist-bit-index-build.sql | text/plain | 773 bytes |