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
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 |