| 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: | Whole Thread | Raw Message | 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 |