Re: v7.2.3 versus v7.3 -> huge performance penalty for JOIN with UNION - Mailing list pgsql-performance
| From | ir. F.T.M. van Vugt bc. |
|---|---|
| Subject | Re: v7.2.3 versus v7.3 -> huge performance penalty for JOIN with UNION |
| Date | |
| Msg-id | 200212021820.06380.ftm.van.vugt@foxi.nl Whole thread Raw |
| In response to | Re: v7.2.3 versus v7.3 -> huge performance penalty for JOIN with UNION (Tom Lane <tgl@sss.pgh.pa.us>) |
| List | pgsql-performance |
Wow, the speed at which you guys are responding never ceases to amaze me !
TL> I don't suppose you have explain output for it from 7.2.3?
Nope, sorry 'bout that.
BTW, the performance comparison was not a 'hard' (measured) number, but a
watch-timed conclusion on a complete run of a conversiontool this query is
part of.
TL> It seems strange to me that the thing is picking a nestloop join here.
TL> oh, but wait: the implicit type coercion from varchar to text is what's
TL> putting the kibosh on a more intelligent join plan.
You're abolutely right, I'm back in business when putting a type coercion
inside the union:
trial=# explain select foo.*, c.id from
<cut>
QUERY PLAN
-------------------------------------------------------------------------------------------------
Sort (cost=588.66..601.10 rows=4976 width=530)
Sort Key: foo.old_id
-> Hash Join (cost=8.84..283.12 rows=4976 width=530)
Hash Cond: ("outer"."key" = "inner".old_creditor_id)
-> Subquery Scan foo (cost=0.00..174.76 rows=4976 width=150)
-> Append (cost=0.00..174.76 rows=4976 width=150)
<cut>
(as opposed to: (cost=54103.74..54116.18 rows=4976 width=498))
> This doesn't explain the slowdown from 7.2.3, though --- it had the same
> deficiency. (I am hoping to get around to fixing it for 7.4.)
Mmm, that's weird. Could be caused by somebody over here who has done 'work'
on some queries... ;( => I'll check on that, if I can be absolutely sure the
7.2.3 version planned *this* query differently, I'll let you know. Sorry
'bout that....
AS> It could easy be that --enable-locale explains the slowdown. Are you
AS> running 7.4 in C locale, or something else?
On v7.2.3. I wasn't doing anything with locale.
The v7.3 put 'POSIX' into the postgresql.conf file, changing that into 'C'
didn't seem to make any difference.
AS> Comparisons in locales like en_US can be *way* slower than in C locale.
AS> You can use pg_controldata to check this for sure.
O.K. this seems to help a lot as well !
I'll have to take a look at both ISO C and POSIX locale, 'cause I wouldn't
have expected it to make such a difference...
On the original v7.3, pg_controldata returned 'posix', upon changing the
postgresql.conf it confirmed the change to 'C'. This resulted in:
POSIX_trial=# explain analyse select foo.*, c.id from
<cut>
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------
Sort (cost=588.66..601.10 rows=4976 width=530) (actual time=2482.51..2530.54
rows=4976 loops=1)
<cut>
Total runtime: 2636.15 msec
C_trial=# explain analyse select foo.*, c.id from
<cut>
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------
Sort (cost=588.66..601.10 rows=4976 width=530) (actual time=1537.05..1549.34
rows=4976 loops=1)
<cut>
Total runtime: 1567.76 msec
Hey, I'm happy ;-)
Thanks a lot !!!
Frank.
pgsql-performance by date: