On 31/7/2022 10:49, Julien Rouhaud wrote:
> On Sat, Jul 30, 2022 at 08:54:33PM +0800, Julien Rouhaud wrote:
> Anyway, 1% is in my opinion still too much overhead for extensions that won't
> get any extra information.
I have read all the thread and still can't understand something. What
valuable data can I find with these extra statistics if no one
parameterized node in the plan exists?
Also, thinking about min/max time in the explain, I guess it would be
necessary in rare cases. Usually, the execution time will correlate to
the number of tuples scanned, won't it? So, maybe skip the time
boundaries in the instrument structure?
In my experience, it is enough to know the total number of tuples
bubbled up from a parameterized node to decide further optimizations.
Maybe simplify this feature up to the one total_rows field in the case
of nloops > 1 and in the presence of parameters?
And at the end. If someone wants a lot of additional statistics, why not
give them that by extension? It is only needed to add a hook into the
point of the node explanation and some efforts to make instrumentation
extensible. But here, honestly, I don't have code/ideas so far.
--
regards,
Andrey Lepikhov
Postgres Professional