On Tue, Jul 27, 2021 at 4:50 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> TBH I do not agree that this is a great idea. I think it's inevitably
> exposing a lot of unstable internal planner details.
Well, that is a risk, but I think I like the alternative even less.
Imagine if we had a CREATE INDEX command but no way -- other than
running queries and noticing how long they seem to take -- to tell
whether it was being used. That would suck, a lot, and this seems to
me to be exactly the same. A user who creates a statistics object has
a legitimate interest in finding out whether that object is doing
anything to a given query that they happen to care about.
> 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. 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?
I don't understand the premise of this question. We don't keep locks
on tables or indexes involved in a plan for the lifetime of a plan, or
on functions or any other kind of object either. We instead arrange to
invalidate the plan if those objects are modified or dropped. Why
would we not use the same approach here?
--
Robert Haas
EDB: http://www.enterprisedb.com