| 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: | Whole Thread | Raw Message | 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 |