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:

Previous
From: Tom Lane
Date:
Subject: Re: v7.2.3 versus v7.3 -> huge performance penalty for JOIN with UNION
Next
From:
Date:
Subject: