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

From Mario Splivalo
Subject Re: Lot'sa joins - performance tip-up, please?
Date
Msg-id 1147325547.8696.6.camel@localhost.localdomain
Whole thread Raw
In response to Re: Lot'sa joins - performance tip-up, please?  ("Jim C. Nasby" <jnasby@pervasive.com>)
Responses Re: Lot'sa joins - performance tip-up, please?
List pgsql-performance
On Wed, 2006-05-10 at 17:10 -0500, Jim C. Nasby wrote:
> 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.

I tried that, no luck. The best performance I achieve with creating
temporary table. And...

>
> Try SET enable_nestloop = off;

This helps also. I don't get sequential scans any more. I'd like a tip
on how to set 'enable_nestloop = off' trough JDBC?

    Mario
--
"I can do it quick, I can do it cheap, I can do it well. Pick any two."

Mario Splivalo
msplival@jagor.srce.hr



pgsql-performance by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Performance/Maintenance test result collection
Next
From: "Zeugswetter Andreas DCP SD"
Date:
Subject: Re: [HACKERS] Big IN() clauses etc : feature proposal