Future directions for inheritance-hierarchy statistics

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Future directions for inheritance-hierarchy statistics
Date: 2015-03-16 20:18:23
Message-ID: 7363.1426537103@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

A few days ago I posted a very-much-WIP patch for making the planner
dynamically combine statistics for each member of an appendrel:
http://www.postgresql.org/message-id/22598.1425686096@sss.pgh.pa.us

That patch was only intended to handle the case of an appendrel generated
by a UNION ALL construct. But it occurs to me that we could easily
change it to also apply to appendrels generated from inheritance trees.
Then we'd no longer need the whole-inheritance-tree statistics that
ANALYZE currently produces, because we'd only ever look at per-table
statistics in pg_statistic.

This would have one significant drawback, which is that planning for
large inheritance trees (many children) would probably get noticeably
slower. (But in the common case that constraint exclusion limits a
query to scanning just one or a few children, the hit would be small.)

On the other hand, there would be two very significant benefits.
First, that we would automatically get statistics that account for
partitions being eliminated by constraint exclusion, because only the
non-eliminated partitions are present in the appendrel. And second,
that we'd be able to forget the whole problem of getting autovacuum
to create whole-inheritance-tree stats. Right now I'm doubtful that
typical users are getting good up-to-date stats at all for queries of
this sort, because autovacuum will only update those stats if it decides
it needs to analyze the parent table. Which is commonly empty, so that
there's never a reason to fire an analyze on it. (We'd left this as
a problem to be solved later when we put in the whole-tree stats
feature in 9.0, but no progress has been made on solving it.)

So I think that going in this direction is clearly a win and we ought
to pursue it. It's not happening for 9.5 of course, because there's
still a great deal of work to do before anything like this would be
committable. But I would like to establish a consensus that this
would be a sensible thing to do in 9.6.

The reason I bring it up now is that the inheritance-for-foreign-tables
patch has some code that I don't much like for controlling what happens
with those whole-tree stats when some of the children are foreign tables
that lack ANALYZE support. If the long-term plan is that whole-tree
stats are going away altogether, then it won't be terribly important
exactly what happens in that case, so we can just do some simple/easy
kluge in the short term and not have to have an argument about what's
the best thing to do.

Comments?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2015-03-16 20:22:55 Re: Additional role attributes && superuser review
Previous Message David G. Johnston 2015-03-16 19:23:17 Re: Providing catalog view to pg_hba.conf file - Patch submission