Re: Rewriting DISTINCT and losing performance - Mailing list pgsql-performance

From Chuck D.
Subject Re: Rewriting DISTINCT and losing performance
Date
Msg-id 200705211217.45205.pgsql-performance@nullmx.com
Whole thread Raw
In response to Re: Rewriting DISTINCT and losing performance  (Richard Huxton <dev@archonet.com>)
Responses Re: Rewriting DISTINCT and losing performance  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On Monday 21 May 2007 11:34, Richard Huxton wrote:
> Chuck D. wrote:
>
> The only thing I can think of is that the CLUSTERing on city.country_id
> makes the system think it'll be cheaper to seq-scan the whole table.
>
> I take it you have got 2 million rows in "city"?

Well here is where it gets strange.  The CLUSTER was just one thing I tried to
do to enhance the performance.  I had the same result prior to cluster.

However, after updating that country_id column to NOT NULL and eliminating
NULL values it will use the country_id index and perform quickly.  Oddly
enough, the original table, world_city still has NULL values in the
country_id column and it has always used the country_id index.

Doesn't that seem a bit strange?  Does it have to do with the smaller size of
the new table maybe?

pgsql-performance by date:

Previous
From: Richard Huxton
Date:
Subject: Re: Rewriting DISTINCT and losing performance
Next
From: "Merlin Moncure"
Date:
Subject: Re: Increasing Shared_buffers = slow commits?