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

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Mario Splivalo <msplival(at)jagor(dot)srce(dot)hr>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Lot'sa joins - performance tip-up, please?
Date: 2006-05-10 22:10:48
Message-ID: 20060510221048.GX99570@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Kris Jurka 2006-05-10 22:16:23 Re: in memory views
Previous Message Thomas Vatter 2006-05-10 21:24:43 Re: in memory views