Re: query slows down with more accurate stats

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

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-performance by date

  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