From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
---|---|
To: | jim(at)nasby(dot)net |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: More tablescanning fun |
Date: | 2003-04-30 14:14:46 |
Message-ID: | iilvavo0jj8frdj6e9a9p6ise3gci5icj7@4ax.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, 25 Apr 2003 09:38:01 -0500, "Jim C. Nasby" <jim(at)nasby(dot)net>
wrote:
>In this case, the interpolation can't be at fault, because correlation
>is 1 (unless the interpolation is backwards, but that doesn't appear to
>be the case).
But your index has 3 columns which causes the index correlation to be
assumed as 1/3. So the interpolation uses 1/9 (correlation squared)
and you get a cost estimation that almost equals the upper bound.
If you want to play around with other interpolation methods, you might
want to get this patch: http://www.pivot.at/pg/16-correlation-732.diff
A short description of the GUC parameters introduced by this patch can
be found here:
http://archives.postgresql.org/pgsql-performance/2002-11/msg00256.php
As a short term workaround for an unmodified Postgres installation,
you can create an index on email_contrib(project_id).
Servus
Manfred
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2003-04-30 14:19:41 | Re: Why LIMIT after scanning the table? |
Previous Message | SZŰCS Gábor | 2003-04-30 11:00:40 | Re: Query Plan far worse in 7.3.2 than 7.2.1 |