Re: AW: AW: Call for alpha testing: planner statistics revi sion s - Mailing list pgsql-hackers

From Tom Lane
Subject Re: AW: AW: Call for alpha testing: planner statistics revi sion s
Date
Msg-id 2207.992881569@sss.pgh.pa.us
Whole thread Raw
In response to AW: AW: Call for alpha testing: planner statistics revi sion s  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
List pgsql-hackers
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at> writes:
> I mean, that it is probably not useful to maintain distribution statistics 
> for a table that is that small at all (e.g. <= 3000 rows and less than
> 512 k size). 

Actually, stats are quite interesting for smaller tables too.  Maybe not
so much for the table itself (ie, deciding between seq and index scan is
not so critical), but to estimate sizes of joins against other tables.

>> Not if it takes hours to get the stats.  I'm more interested in keeping
>> ANALYZE cheap and encouraging DBAs to run it frequently, so that the
>> stats stay up-to-date.  It doesn't matter how perfect the stats were
>> when they were made, if the table has changed since then.

> That is true, but this is certainly a tradeoff situation. For a huge table
> that is quite static you would certainly want most accurate statistics even
> if it takes hours to compute once a month.

Sure.  My thought is that one would do this by increasing the SET
STATISTICS targets for such tables, thus yielding more detailed stats
that take longer to compute.  What we need now is experimentation to
find out how well this works in practice.  It might well be that more
knobs will turn out to be useful, but let's not add complexity until
we've proven it to be necessary ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: UNIQUE INDEX unaware of transactions (a spin ofquestion)
Next
From: "gabriel"
Date:
Subject: POSTMASTER