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-16 10:16:11 |
Message-ID: | hjau701l6u8kavv7ukrqprugi2bkuocd2a@email.aon.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On Thu, 15 Apr 2004 20:18:49 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> getting several tuples from the same page is more likely
>> than with the old method.
>
>Hm, are you sure?
Almost sure. Let's look at a corner case: What is the probability of
getting a sample with no two tuples from the same page? To simplify the
problem assume that each page contains the same number of tuples c.
If the number of pages is B and the sample size is n, a perfect sampling
method collects a sample where all tuples come from different pages with
probability (in OpenOffice.org syntax):
p = prod from{i = 0} to{n - 1} {{c(B - i)} over {cB - i}}
or in C:
p = 1.0;
for (i = 0; i < n; ++i)
p *= c*(B - i) / (c*B - i)
This probability grows with increasing B.
>Also, I'm not at all sure that the old method satisfies that constraint
>completely in the presence of nonuniform numbers of tuples per page,
>so we'd not necessarily be going backwards anyhow ...
Yes, it boils down to a decision whether we want to replace one not
quite perfect sampling method with another not quite perfect method.
I'm still working on putting together the pros and cons ...
Servus
Manfred
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2004-04-16 12:10:20 | Re: Socket communication for contrib |
Previous Message | Christopher Kings-Lynne | 2004-04-16 02:41:10 | Re: [HACKERS] Remove MySQL Tools from Source? |
From | Date | Subject | |
---|---|---|---|
Next Message | Dirk Lutzebäck | 2004-04-16 13:03:28 | RESOLVED: Re: Wierd context-switching issue on Xeon |
Previous Message | Rajesh Kumar Mallah | 2004-04-16 08:23:50 | Re: [ SOLVED ] select count(*) very slow on an already |