From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: query slows down with more accurate stats |
Date: | 2004-04-15 23:32:53 |
Message-ID: | ri5u70du80gnnt326k2hhuei5nlnimonbs@email.aon.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
[Just a quick note here; a more thorough discussion of my test results
will be posted to -hackers]
On Tue, 13 Apr 2004 15:18:42 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Well, the first problem is why is ANALYZE's estimate of the total row
>count so bad :-( ? I suspect you are running into the situation where
>the initial pages of the table are thinly populated and ANALYZE
>mistakenly assumes the rest are too. Manfred is working on a revised
>sampling method for ANALYZE that should fix this problem
The new method looks very promising with respect to row count
estimation: I got estimation errors of +/- 1% where the old method was
off by up to 60%. (My test methods might be a bit biased though :-))
My biggest concern at the moment is that the new sampling method
violates the contract of returning each possible sample with he same
probability: getting several tuples from the same page is more likely
than with the old method.
Servus
Manfred
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-04-15 23:52:59 | Re: signal 11 on AIX: 7.4.2 |
Previous Message | Kevin Brown | 2004-04-15 22:49:01 | Re: PostgreSQL configuration |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-04-16 00:18:49 | Re: query slows down with more accurate stats |
Previous Message | Manfred Koizar | 2004-04-15 23:04:24 | Re: index v. seqscan for certain values |