From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Tomas Vondra <tomas(at)vondra(dot)me> |
Cc: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
Subject: | Re: Adding skip scan (including MDAM style range skip scan) to nbtree |
Date: | 2025-05-09 16:36:23 |
Message-ID: | CAH2-Wzkw-6-nz7vChxZtfOwEXxm=JSqvB=7RVOrbdc1mmi1k5Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 9, 2025 at 12:28 PM Tomas Vondra <tomas(at)vondra(dot)me> wrote:
> Not sure if it matters, but this uses index-only scans, and the pages
> are all-visible, so maybe it's not much more expensive.
You're still going to have to scan 85 full index pages on your
pgbench_accounts.bid index -- that's pretty expensive, even with an
index-only scan.
Even if there was some kind of really obvious regression in
preprocessing (which seems almost impossible), I'd still expect it to
be drowned out for queries such as these.
> Not sure, I did multiple tests with different queries, and it'd be a bit
> strange if this was the only one affected. Not impossible.
The only thing that substantially differs between this
pgbench_accounts.bid query and traditional pgbench SELECT queries (on
pgbench_accounts.aid) is 1.) this query is quite a bit more expensive
at execution time, and 2.) that it involves the use of partitioning.
I made sure to test pgbench SELECT quite thoroughly -- that certainly
wasn't regressed. So it seems very likely to have something to do with
partitioning.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2025-05-09 16:38:02 | Re: Adding skip scan (including MDAM style range skip scan) to nbtree |
Previous Message | Tom Lane | 2025-05-09 16:32:30 | Re: Why our Valgrind reports suck |