Re: Huge query stalls at PARSE/BIND stage (1)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Matt <msubs(at)philips(dot)org(dot)uk>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Huge query stalls at PARSE/BIND stage (1)
Date: 2005-11-17 18:27:19
Message-ID: 29674.1132252039@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Matt <msubs(at)philips(dot)org(dot)uk> writes:
> Yesterday I added 20 more join statements to the query (identical to
> existing statements) and now the main query which would run in <30
> seconds, runs indefinitely with the process stuck at "PARSE" in version
> 7.4, or "BIND" in version 8.0.3.

You *really* need to rethink your database design :-( ... thirty-way
JOINs are just not a very good idea.

Having said that, though, the fact that they're all outer joins should
save you from an exponential blowup in planning time, because there's
only one legal join order. I'm not sure where the time is going.

If you'd be willing to send me a test case off-list, I'd be willing to
take a look. A convenient test case from my point of view would be a
SQL script that sets up the database plus another one containing the
slow query.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David Fetter 2005-11-17 20:07:00 BUG #2051: CREATE TEMP TABLE AS SELECT doesn't play nice with ON COMMIT DROP
Previous Message Johannes 2005-11-17 18:00:35 BUG #2050: Bad plan by using of LIKE