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.
--
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 |
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? |