public inbox for [email protected]
help / color / mirror / Atom feedFrom: Lukas Fittl <[email protected]>
To: Justin Pryzby <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [PATCH] Add extra statistics to explain for Nested Loop
Date: Thu, 6 Jan 2022 19:33:28 -0800
Message-ID: <CAP53Pkw1d+smuPvsVDecSnfphyZ46zrkSNjNEbSF3HA6-EsFkA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<CAOBaU_Yj6gdcc7q_CYWWMByMSUt29pO2Vky6xk9eP2g1rw_Eww@mail.gmail.com>
<[email protected]>
<20201031012053.arjh7eehmlzud45p@development>
<[email protected]>
<[email protected]>
<CAOBaU_aN4oSGXJTrgN4k44g0Z1_2cASEnaGd2M3pdRdbiQdxuQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
On Sun, Nov 21, 2021 at 8:55 PM Justin Pryzby <[email protected]> wrote:
> I'm curious to hear what you and others think of the refactoring.
>
> It'd be nice if there's a good way to add a test case for verbose output
> involving parallel workers, but the output is unstable ...
>
I've reviewed this patch, and it works as expected - the refactoring
changes by Justin also appear to make sense to me.
I've briefly thought whether this needs documentation (currently the patch
includes none), but there does not appear to be a good place to add
documentation about this from a quick glance, so it seems acceptable to
leave this out given the lack of more detailed EXPLAIN documentation in
general.
The one item that still feels a bit open to me is benchmarking, based on
Andres' comment a while ago:
On Mon, Oct 19, 2020 at 4:20 PM Andres Freund <[email protected]> wrote:
> I'm a bit worried that further increasing the size of struct
> Instrumentation will increase the overhead of EXPLAIN ANALYZE further -
> in some workloads we spend a fair bit of time in code handling that. It
> would be good to try to find a few bad cases, and see what the overhead is.
>
Whilst no specific bad cases were provided, I wonder if even a simple
pgbench with auto_explain (and log_analyze=1) would be a way to test this?
The overhead of the Instrumentation struct size should show regardless of
whether a plan actually includes a Nested Loop.
Thanks,
Lukas
--
Lukas Fittl
view thread (2+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: [PATCH] Add extra statistics to explain for Nested Loop
In-Reply-To: <CAP53Pkw1d+smuPvsVDecSnfphyZ46zrkSNjNEbSF3HA6-EsFkA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox