[PERFORM] Query plan for very large number of joins

2005-06-02 Thread philb
Hi, I am using PostgreSQL (7.4) with a schema that was generated automatically (using hibernate). The schema consists of about 650 relations. One particular query (also generated automatically) consists of left joining approximately 350 tables. At this stage, most tables are empty and those

Re: [PERFORM] Query plan for very large number of joins

2005-06-03 Thread philb
>>> I am using PostgreSQL (7.4) with a schema that was generated >>> automatically (using hibernate). The schema consists of about 650 >>> relations. One particular query (also generated automatically) >>> consists of left joining approximately 350 tables. [snip] >One thought is that I am not s

Re: [PERFORM] Query plan for very large number of joins

2005-06-03 Thread philb
Anyone following this thread might be interested to know that disabling the merge and hash joins (as suggested below) resulted in the execution time dropping from ~90 seconds to ~35 seconds. Disabling GEQO has brought about a marginal reduction (~1 second, pretty much within the the margin of

Re: [PERFORM] Query plan for very large number of joins

2005-06-04 Thread philb
>> Despite being fairly restricted in scope, >> the schema is highly denormalized hence the large number of tables. > >Do you mean normalized? Or do you mean you've pushed the superclass >details down onto each of the leaf classes? Sorry, I meant normalized, typing faster than I'm thinking here:)