Re: same plan, add 1 condition, 1900x slower

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mitch Skinner <mitch(at)egcrc(dot)net>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: same plan, add 1 condition, 1900x slower
Date: 2005-11-10 17:23:20
Message-ID: 10164.1131643400@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Mitch Skinner <mitch(at)egcrc(dot)net> writes:
> This is with Postgres 8.0.3. Any advice is appreciated.

These are exactly the same plan, except for the addition of the extra
filter condition ...

> -> Index Scan using external_id_map_primary_key on external_id_map
> eim (cost=0.00..2345747.01 rows=15560708 width=26) (actual
> time=0.061..2.944 rows=2175 loops=1)

> -> Index Scan using external_id_map_primary_key on external_id_map
> eim (cost=0.00..2384648.78 rows=4150 width=26) (actual
> time=0.020..21068.508 rows=1186 loops=1)
> Filter: (source = 'SCH'::bpchar)

Apparently, you are using a platform and/or locale in which strcoll() is
spectacularly, god-awfully slow --- on the order of 10 msec per comparison.
This is a bit hard to believe but I can't make sense of those numbers
any other way. What is the platform exactly, and what database locale
and encoding are you using?

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2005-11-10 17:44:15 Re: WAL sync behaviour
Previous Message Scott Marlowe 2005-11-10 17:00:10 Re: WAL sync behaviour