On Wed, Jan 30, 2008 at 09:13:37PM -0500, Christopher Browne wrote:
> There seems to be *plenty* of evidence out there that the performance
> penalty would NOT be "essentially zero."
>
> Tom points out:
> eqjoinsel(), for one, is O(N^2) in the number of MCV values kept.
>
> It seems to me that there are cases where we can *REDUCE* the
> histogram width, and if we do that, and then pick and choose the
> columns where the width increases, the performance penalty may be
> "yea, verily *actually* 0."
>
> This fits somewhat with Simon Riggs' discussion earlier in the month
> about Segment Exclusion; these both represent cases where it is quite
> likely that there is emergent data in our tables that can help us to
> better optimize our queries.
This is all still hand-waving until someone actually measures what the
impact of the stats target is on planner time. I would suggest actually
measuring that before trying to invent more machinery. Besides, I think
you'll need that data for the machinery to make an intelligent decision
anyway...
BTW, with autovacuum I don't really see why we should care about how
long analyze takes, though perhaps it should have a throttle ala
vacuum_cost_delay.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828