Re: Showing primitive index scan count in EXPLAIN ANALYZE (for skip scan and SAOP scans)
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Alena Rybakina <a.rybakina@postgrespro.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-11-12T20:00:01Z
Lists: pgsql-hackers
On Sun, Nov 10, 2024 at 2:00 PM Alena Rybakina <a.rybakina@postgrespro.ru> wrote: > Or maybe I was affected by fatigue, but I don’t understand this point, to be honest. I see from the documentation and your first letter that it specifies how many times in total the tuple search would be performed during the index execution. Is that not quite right? Well, nodes that appear on the inner side of a nested loop join (and in a few other contexts) generally have their row counts (and a few other things) divided by the total number of executions. The idea is that we're showing the average across all executions of the node -- if the user wants the true absolute number, they're expected to multiply nrows by nloops themselves. This is slightly controversial behavior, but it is long established (weirdly, we never divide by nloops for "Buffers"). Initial versions of my patch didn't do this. The latest version does divide like this, though. In general it isn't all that likely that an inner index scan would have more than a single primitive index scan, in any case, so which particular behavior I use here (divide vs don't divide) is not something that I feel strongly about. >> Why wouldn't they expect to continue to see the same information (or >> similar information) when the index searches happen to be coordinated >> by the index scan node/index AM itself? > > To be honest, I don't quite understand this. Can you please explain in more detail? I just meant that your OR transformation patch is another case where we shouldn't obscure the count of primitive index scans. It would be inconsistent of us to allow users to see the number of index scans today (without your patch), while denying users the ability to see essentially the same information in the future (with your patch). The fact that an index scan has its own executor node today and won't have one tomorrow shouldn't in itself affect instrumentation of the number of (primitive) index scans shown by EXPLAIN ANALYZE (it certainly won't affect the instrumentation within the pg_stat_all_indexes view, as things stand, even without my patch). -- Peter Geoghegan
Commits
-
Show index search count in EXPLAIN ANALYZE, take 2.
- 0fbceae841cb 18.0 landed
-
Show index search count in EXPLAIN ANALYZE.
- 5ead85fbc811 18.0 landed
-
Allow usage of match_orclause_to_indexcol() for joins
- 627d63419e22 18.0 cited
-
Fix nbtree pgstats accounting with parallel scans.
- c00c54a9ac1e 18.0 landed
- fb4f5e58af97 17.0 landed
-
Enhance nbtree ScalarArrayOp execution.
- 5bf748b86bc6 17.0 cited
-
Fix EXPLAIN ANALYZE of hash join when the leader doesn't participate.
- 5bcf389ecfd4 11.0 cited