Re: Lot'sa joins - performance tip-up, please? - Mailing list pgsql-performance

From Jim C. Nasby
Subject Re: Lot'sa joins - performance tip-up, please?
Date
Msg-id 20060510221048.GX99570@pervasive.com
Whole thread Raw
In response to Re: Lot'sa joins - performance tip-up, please?  (Mario Splivalo <msplival@jagor.srce.hr>)
Responses Re: Lot'sa joins - performance tip-up, please?
List pgsql-performance
On Thu, May 04, 2006 at 04:45:57PM +0200, Mario Splivalo wrote:
Well, here's the problem...

>          ->  Nested Loop  (cost=0.00..176144.30 rows=57925 width=26)
> (actual time=1074.984..992536.243 rows=57925 loops=1)
>                ->  Seq Scan on ticketing_codes_played
> (cost=0.00..863.25 rows=57925 width=8) (actual time=74.479..2047.993
> rows=57925 loops=1)
>                ->  Index Scan using ticketing_codes_pk on
> ticketing_codes  (cost=0.00..3.01 rows=1 width=18) (actual
> time=17.044..17.052 rows=1 loops=57925)
>                      Index Cond: (ticketing_codes.code_id =
> "outer".code_id)

Anyone have any idea why on earth it's doing that instead of a hash or
merge join?

In any case, try swapping the order of ticketing_codes_played and
ticketing_codes. Actually, that'd probably make it worse.

Try SET enable_nestloop = off;
--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

pgsql-performance by date:

Previous
From: Thomas Vatter
Date:
Subject: Re: in memory views
Next
From: Kris Jurka
Date:
Subject: Re: in memory views