Skip site navigation (1) Skip section navigation (2)

Re: Simply join in PostrgeSQL takes too long

From: Manfred Koizar <mkoi-pg(at)aon(dot)at>
To: Rod Taylor <pg(at)rbt(dot)ca>
Cc: Vitaly Belman <vitalib(at)012(dot)net(dot)il>,Postgresql Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Simply join in PostrgeSQL takes too long
Date: 2004-04-28 08:24:41
Message-ID: tlpu80tqhmnpc2sl63boejki6o4vbn1p3q@email.aon.at (view raw or flat)
Thread:
Lists: pgsql-performance
On Tue, 27 Apr 2004 18:01:34 -0400, Rod Taylor <pg(at)rbt(dot)ca> wrote:
>On Tue, 2004-04-27 at 17:27, Vitaly Belman wrote:
>> Hello pgsql-performance,
>> 
>>   I discussed the whole subject for some time in DevShed and didn't
>>   achieve much (as for results). I wonder if any of you guys can help
>>   out:
>> 
>>   http://forums.devshed.com/t136202/s.html

>The point is that a book cannot be of a certain genre more than once.

Rod, he has a hierarchy of genres.  Genre 1 has 6379 child genres and a
book can be in more than one of these.

Vitaly, though LIMIT makes this look like a small query, DISTINCT
requires the whole result set to be retrieved.  0.7 seconds doesn't look
so bad for several thousand rows.  Did you try with other genre_ids?

Maybe a merge join is not the best choice.  Set enable_mergejoin to
false and see whether you get a (hopefully faster) hash join, assuming
that sort_mem is large enough to keep the hash table in memory.

If you send me your table contents I'll try it on Linux.

Servus
 Manfred

In response to

Responses

pgsql-performance by date

Next:From: Christopher Kings-LynneDate: 2004-04-28 08:25:26
Subject: Re: [JDBC] [PERFORM] is a good practice to create an index on the
Previous:From: Suller AndrĂ¡sDate: 2004-04-28 08:15:19
Subject: Re: Join problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group