Re: index scan on =, but not < ?

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.

In response to

Responses

Browse pgsql-performance by date

  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 < ?