Re: [PERFORM] Bad n_distinct estimation; hacks suggested? - Mailing list pgsql-hackers

From Rod Taylor
Subject Re: [PERFORM] Bad n_distinct estimation; hacks suggested?
Date
Msg-id 1114560992.77587.112.camel@home
Whole thread Raw
In response to Re: [PERFORM] Bad n_distinct estimation; hacks suggested?  (Greg Stark <gsstark@mit.edu>)
Responses Re: [PERFORM] Bad n_distinct estimation; hacks suggested?
List pgsql-hackers
On Tue, 2005-04-26 at 19:28 -0400, Greg Stark wrote:
> Rod Taylor <rbt@sitesell.com> writes:
> 
> > On Tue, 2005-04-26 at 19:03 -0400, Greg Stark wrote:
> > > This one looks *really* good. 
> > > 
> > >  http://www.aladdin.cs.cmu.edu/papers/pdfs/y2001/dist_sampl.pdf
> > > 
> > > It does require a single full table scan 
> > 
> > Ack.. Not by default please.
> > 
> > I have a few large append-only tables (vacuum isn't necessary) which do
> > need stats rebuilt periodically.
> 
> The algorithm can also naturally be implemented incrementally. Which would be
> nice for your append-only tables. But that's not Postgres's current philosophy
> with statistics. Perhaps some trigger function that you could install yourself
> to update statistics for a newly inserted record would be useful.

If when we have partitions, that'll be good enough. If partitions aren't
available this would be quite painful to anyone with large tables --
much as the days of old used to be painful for ANALYZE.

-- 



pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: DO INSTEAD and conditional rules
Next
From: Brent Verner
Date:
Subject: Re: [proposal] protocol extension to support loadable stream filters