Re: [PERFORM] Bad n_distinct estimation; hacks suggested?

From: Rod Taylor <pg(at)rbt(dot)ca>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org, Gurmeet Manku <manku(at)cs(dot)stanford(dot)edu>
Subject: Re: [PERFORM] Bad n_distinct estimation; hacks suggested?
Date: 2005-04-27 00:16:32
Message-ID: 1114560992.77587.112.camel@home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

On Tue, 2005-04-26 at 19:28 -0400, Greg Stark wrote:
> Rod Taylor <rbt(at)sitesell(dot)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.

--

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brent Verner 2005-04-27 00:31:18 Re: [proposal] protocol extension to support loadable stream filters
Previous Message Jan Wieck 2005-04-27 00:02:43 Re: DO INSTEAD and conditional rules

Browse pgsql-performance by date

  From Date Subject
Next Message Mike Rylander 2005-04-27 00:42:10 Re: Table Partitioning: Will it be supported in Future?
Previous Message Josh Berkus 2005-04-27 00:00:13 Re: Table Partitioning: Will it be supported in Future?