Re: Simply join in PostrgeSQL takes too long

Hello Manfred,

I thank everyone for helping me on this - So many tips.

I am in the middle of going through them all, till now disabling the
enable_mergejoin really helped.

Also, I agree that the design might be flawed (I could use triggers
and stuff like that) but for now I am just comparing how my project
will run on PostgreSQL (Considering migration from MySQL).

I'll be reporting back on how the other stuff helped.

Regards,
Vitaly Belman

ICQ: 1912453
AIM: VitalyB1984
MSN: tmdagent(at)hotmail(dot)com
Yahoo!: VitalyBe

Wednesday, April 28, 2004, 11:24:41 AM, you wrote:

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

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

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

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

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

MK> Servus
MK> Manfred