From: | Andrey Borodin <amborodin86(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Buffer usage detailed by RelKind in EXPLAIN ANALYZE BUFFERS |
Date: | 2023-02-14 00:23:30 |
Message-ID: | CAAhFRxgVg+EbdyryZ8BOdrMtkfYPYxfi99v5-Cg2GBO+JEb1JQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi hackers!
I was asked to prototype a feature that helps to distinguish shared
buffer usage between index reads and heap reads. Practically it looks
like this:
# explain (analyze,verbose,buffers) select nextval('s');
QUERY PLAN
------------------------------------------------------------------------------------------------
Result (cost=0.00..0.01 rows=1 width=8) (actual time=1.159..1.160
rows=1 loops=1)
Output: nextval('s'::regclass)
Buffers: shared hit=7(relation 3, index 4) read=6(relation 1, index
4, sequence 1) dirtied=1
Planning Time: 0.214 ms
Execution Time: 1.238 ms
(5 rows)
The change is in these parts "(relation 3, index 4)" and "(relation 1,
index 4, sequence 1)". Probably, it should help DBAs to better
understand complex queries.
I think cluttering output with more text is OK as long as "verbose" is
requested.
But there are some caveats:
1. Some more increments on hot paths. We have to add this tiny toll to
every single buffer hit, but it will be seldom of any use.
2. It's difficult to measure writes caused by query, and even dirties.
The patch adds "evictions" caused by query, but they have little
practical sense too.
All in all I do not have an opinion if this feature is a good tradeoff.
What do you think? Does the feature look useful? Do we want a more
polished implementation?
Thanks!
Best regards, Andrey Borodin.
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Split-EXPLAIN-ANALYZE-BUFFERS-by-RelKind.patch | application/octet-stream | 11.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-02-14 00:26:27 | Re: Add the ability to limit the amount of memory that can be allocated to backends. |
Previous Message | Andres Freund | 2023-02-14 00:20:04 | Re: pgbench: using prepared BEGIN statement in a pipeline could cause an error |