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
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 |