Re: More tablescanning fun

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

In response to

Responses

Browse pgsql-performance by date

  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