Re: Stats for inheritance trees - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Stats for inheritance trees
Date
Msg-id 11961.1262118743@sss.pgh.pa.us
Whole thread Raw
In response to Stats for inheritance trees  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Stats for inheritance trees
List pgsql-hackers
I wrote:
> Following up on the discussion here
> http://archives.postgresql.org/message-id/4B3875C6020000250002D97D@gw.wicourts.gov
> I'd like to propose making the following changes that would allow saner
> planning for queries involving inheritance:

I've committed the easy aspects of this (still need to work on autovacuum).
I ran into one unexpected loose end: what shall we do with ALTER TABLE
SET STATISTICS DISTINCT?

As committed, any manually set value of attdistinct will be applied to
both the relation-local and inherited stats for the column.  From a
logical standpoint this is clearly the Wrong Thing, because it's quite
possible that different values would be needed.  On the other hand,
I'm not sure how much it matters in practice.  In the typical cases
where you need to force a value, you're probably going to force a
fractional value, and those would be likely be OK for both.

The only "real" fix I could see would be to create an additional
pg_attribute column and a separate command to set it.  But it really
doesn't seem worth that much trouble.

Or we could think about some heuristics, like applying the manual
value to inherited stats only if it's fractional (negative).
But I'm afraid any rule like that would get in the way as often
as it would help.

Thoughts?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: quoting psql varible as identifier
Next
From: Simon Riggs
Date:
Subject: Re: Cancelling idle in transaction state