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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

  From Date Subject
Next Message Christopher Kings-Lynne 2004-04-28 08:25:26 Re: [JDBC] [PERFORM] is a good practice to create an index on the
Previous Message Suller András 2004-04-28 08:15:19 Re: Join problem