From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Showing primitive index scan count in EXPLAIN ANALYZE (for skip scan and SAOP scans) |
Date: | 2024-08-27 17:45:08 |
Message-ID: | CA+TgmobGZUZtaApnx60KLE8df0QfiJ3rgAT3xp9KkREPuEpZqg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 27, 2024 at 11:16 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> On Thu, Aug 15, 2024 at 3:22 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> > Attached patch has EXPLAIN ANALYZE display the total number of
> > primitive index scans for all 3 kinds of index scan node.
>
> Attached is v2, which fixes bitrot.
>
> v2 also uses new terminology. EXPLAIN ANALYZE will now show "Index
> Searches: N", not "Primitive Index Scans: N". Although there is
> limited precedent for using the primitive scan terminology, I think
> that it's a bit unwieldy.
I do like "Index Searches" better than "Primitive Index Scans."
But I think Matthias had some good points about this being
btree-specific. I'm not sure whether he was completely correct, but
you seemed to just dismiss his argument and say "well, that can't be
done," which doesn't seem convincing to me at all. If, for non-btree
indexes, the number of index searches will always be the same as the
loop count, then surely there is some way to avoid cluttering the
output for non-btree indexes with output that can never be of any use.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Ayush Vatsa | 2024-08-27 17:47:00 | Re: Proposal to have INCLUDE/EXCLUDE options for altering option values |
Previous Message | Robert Haas | 2024-08-27 17:17:48 | Re: allowing extensions to control planner behavior |