"Kevin Grittner" <Kevin.Grittner@xxxxxxxxxxxx> writes: > Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >> The approach contemplated in the comment, of assembling some stats >> on-the-fly from the stats for individual child tables, doesn't >> seem real practical from a planning-time standpoint. > Can you give a thumbnail sketch of why that is? Well, it would be expensive, and it's not even clear you can do it at all (merging histograms with overlapping bins seems like a mess for instance). I think we have previously discussed the idea of generating and storing ANALYZE stats for a whole inheritance tree, which'd solve the problem nicely from the planner's standpoint. I'm a bit worried about the locking implications, but if it took just a SELECT lock on the child tables it probably wouldn't be too bad --- no worse than any other SELECT on the inheritance tree. Another thing that's hard to figure out is how autovacuum would know when to redo the stats. In a lot of common situations, the inheritance parent table is empty and never changes, so no autovac or autoanalyze would ever get launched against it. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance