From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: EXPLAIN BUFFERS and I/O timing accounting questions |
Date: | 2019-10-24 21:25:12 |
Message-ID: | 20191024212512.fwdub7zyaboolsxn@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Hi,
On 2019-10-21 23:18:32 -0700, Maciek Sakrejda wrote:
> I ran across an EXPLAIN plan and had some questions about some of its
> details. The BUFFERS docs say
>
> >The number of blocks shown for an upper-level node includes those used by
> all its child nodes.
>
> I initially assumed this would be cumulative, but I realized it's probably
> not because some of the blocks affected by each child will actually
> overlap.
Note that the buffer access stats do *not* count the number of distinct
buffers accessed, but that they purely the number of buffer
accesses.
It'd be really expensive to count the number of distinct buffers
accessed, although I guess one could make it only expensive by using
something like hyperloglog (although that will still be hard, due to
buffer replacement etc).
> But this particular plan has a Shared Hit Blocks at the root (an
> Aggregate) that is smaller than some of its children (three ModifyTables
> and a CTE Scan).
Do you have an example? I assume what's going on is that the cost of
the CTE is actually attributed (in equal parts or something like that)
to all places using the CTE. Do the numbers add up if you just exclude
the CTE?
> This seems to contradict the documentation (since if
> children overlap fully in their buffers usage, the parent should still have
> a cost equal to the costliest child)--any idea what's up? I can send the
> whole plan (attached? inline? it's ~15kb) if that helps.
Or just relevant top-level excerpts.
> Also, a tangential question: why is the top-level structure of a JSON plan
> an array? I've only ever seen one root node with a Plan key there.
IIRC one can get multiple plans when there's a DO ALSO rule. There might
be other ways to get there too.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | stan | 2019-10-24 21:58:06 | Re: A very puzzling backup/restore problem |
Previous Message | Tom Lane | 2019-10-24 20:17:58 | Re: jsonb_set() strictness considered harmful to data |
From | Date | Subject | |
---|---|---|---|
Next Message | Victor Spirin | 2019-10-24 21:31:11 | Re: psql tab-complete |
Previous Message | Andres Freund | 2019-10-24 21:10:27 | Re: tuplesort test coverage |