<[EMAIL PROTECTED]> writes:
> Thanks for the suggestion. I've timed both the EXPLAIN and the EXPLAIN
> ANALYZE operations.
> Both operations took 1m 37s. The analyze output indicates that the query
> execution time was 950ms. This doesn't square with the JDBC prepareStatement
> executing in 36ms. My guess is that the prepare was actually a no-op but
> I haven't found anything about this yet.
Only in very recent JDBCs does prepareStatement do much of anything.
> So, is it correct to interpret this as the query planner taking an
> awful long time?
Looks that way.
> Is it possible to force the query planner to adopt a specific strategy
> and not search for alternatives (I'm aware of the noXX options, it's the
> reverse logic that I'm thinking of here).
There's no positive forcing method. But you could probably save some
time by disabling both mergejoin and hashjoin, now that you know it's
going to end up picking nestloop for each join anyway. Even more
important: are you sure that *every* one of the joins is a LEFT JOIN?
Even a couple of regular joins will let it fool around choosing
different join orders.
> Alternatively, is there some way to check if the query planner is
> bottlenecking on a specific resource?
I think it would be interesting to try profiling it. I'm not really
expecting to find anything easily-fixable, but you never know. From
what you said before, the database is not all that large --- would
you be willing to send me a database dump and the text of the query
off-list?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
