From: | David Brown <time(at)bigpond(dot)net(dot)au> |
---|---|
To: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
Cc: | pgsql-performance(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: index scan on =, but not < ? |
Date: | 2005-03-10 00:24:46 |
Message-ID: | 422F93CE.10400@bigpond.net.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Jim C. Nasby wrote:
>Ahh, I was thinking of a high correlation factor on the index. I still
>question 5% though... that seems awefully low.
>
>
Not really. It all depends on how many records you're packing into each
page. 1% may well be the threshold for small records.
Tom mentioned this in the last couple of months. He was citing a uniform
distribution as an example and I thought that sounded a little
pessimistic, but when I did the (possibly faulty) math with a random
distribution, I discovered he wasn't far off.
It's not this simple, but if you can fit 50 randomly organized records
into each page and you want to retrieve 2% of the rows, it's likely
you'll have to fetch every page - believe it or not.
What concerns me is that this all depends on the correlation factor, and
I suspect that the planner is not giving enough weight to this.
Actually, I'm wondering if it's even looking at the statistic, but I
haven't created a test to check. It might explain quite a few complaints
about the planner not utilizing indexes.
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Johannsen | 2005-03-10 02:09:20 | Re: Help trying to tune query that executes 40x slower |
Previous Message | David Brown | 2005-03-10 00:06:23 | Re: index scan on =, but not < ? |