Re: Rewriting DISTINCT and losing performance

From: "Chuck D(dot)" <pgsql-performance(at)nullmx(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Rewriting DISTINCT and losing performance
Date: 2007-05-21 18:17:44
Message-ID: 200705211217.45205.pgsql-performance@nullmx.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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?

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Merlin Moncure 2007-05-21 18:40:10 Re: Increasing Shared_buffers = slow commits?
Previous Message Richard Huxton 2007-05-21 17:34:11 Re: Rewriting DISTINCT and losing performance