Re: Showing applied extended statistics in explain

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Showing applied extended statistics in explain
Date: 2021-07-27 21:38:53
Message-ID: f429ac9e-5fa1-3cae-4fd3-1aadfd258847@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 7/27/21 10:50 PM, Tom Lane wrote:
> Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> writes:
>> On 7/27/21 12:21 PM, Dmitry Dolgov wrote:
>>>> So it seems useful to include this into in the explain plan - show which
>>>> statistics were applied, in which order. Attached is an early PoC patch
>>>> doing that in VERBOSE mode. I'll add it to the next CF.
>
>> Yes. I think providing more insight into which statistics were applied,
>> in which order and to which clauses, is quite desirable.
>
> TBH I do not agree that this is a great idea. I think it's inevitably
> exposing a lot of unstable internal planner details.

Which unstable planner details? IMHO it's not all that different from
info about which indexes were picked for the query.

> I like even less the aspect that this means a lot of information has
> to be added to the finished plan in case it's needed for EXPLAIN.
Yes, that's true. I mentioned that in my initial post, and I suggested
we might collect it only when in explain mode.

> Aside from the sheer cost of copying that data around, what happens
> if for example somebody drops a statistic object between the time of
> planning and the EXPLAIN? Are we going to start keeping locks on
> those objects for the lifetime of the plans?
>

Yes, that'd be an issue. I'm not sure what to do about it, short of
either locking the (applied) statistics objects, or maybe just simply
copying the bits we need for explain (pretty much just name).

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2021-07-27 22:24:36 Re: [PATCH] test/ssl: rework the sslfiles Makefile target
Previous Message Heikki Linnakangas 2021-07-27 21:25:09 Re: Why don't update minimum recovery point in xact_redo_abort