Re: Custom explain options

From: Konstantin Knizhnik <knizhnik(at)garret(dot)ru>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Custom explain options
Date: 2024-01-10 13:27:06
Message-ID: 6c58f5b4-0b6d-4dea-8085-7e9ce13172e1@garret.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 10/01/2024 8:46 am, Michael Paquier wrote:
> On Wed, Jan 10, 2024 at 01:29:30PM +0700, Andrei Lepikhov wrote:
>> What do you think about this really useful feature? Do you wish to develop
>> it further?
> I am biased here. This seems like a lot of code for something we've
> been delegating to the explain hook for ages. Even if I can see the
> appeal of pushing that more into explain.c to get more data on a
> per-node basis depending on the custom options given by the caller of
> an EXPLAIN entry point, I cannot get really excited about the extra
> maintenance this facility would involve compared to the potential
> gains, knowing that there's a hook.
> --
> Michael

Well, I am not sure that proposed patch is flexible enough to handle all
possible scenarios.
I just wanted to make it as simple as possible to leave some chances for
it to me merged.
But it is easy to answer the question why existed explain hook is not
enough:

1. It doesn't allow to add some extra options to EXPLAIN. My intention
was to be able to do something like this "explain
(analyze,buffers,prefetch) ...". It is completely not possible with
explain hook.
2. May be I wrong, but it is impossible now to collect and combine
instrumentation from all parallel workers without changing Postgres core

Explain hook can be useful if you add some custom node to query
execution plan and want to provide information about this node.
But if you are implementing some alternative storage mechanism or some
optimization for existed plan nodes, then it is very difficult to do it
using existed explain hook.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dagfinn Ilmari Mannsåker 2024-01-10 13:27:50 Re: System username in pg_stat_activity
Previous Message Dilip Kumar 2024-01-10 13:20:20 Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock