Re: Should from_collapse be switched off? (queries 10 times faster) - Mailing list pgsql-performance

From Laurenz Albe
Subject Re: Should from_collapse be switched off? (queries 10 times faster)
Date
Msg-id 1521954728.2350.24.camel@cybertec.at
Whole thread Raw
In response to Re: Should from_collapse be switched off? (queries 10 times faster)  (Peter <pmc@citylink.dinoex.sub.org>)
Responses Re: Should from_collapse be switched off? (queries 10 times faster)  (Peter <pmc@citylink.dinoex.sub.org>)
List pgsql-performance
Peter wrote:
> On Fri, Mar 23, 2018 at 10:14:19AM -0400, Tom Lane wrote:
> 
> ! It's conceivable that the OP's problem is actually planning time
> ! (if the query joins sufficiently many tables) and that restricting
> ! the cost of the join plan search is really what he needs to do.
> 
> Negative. Plnning time 10 to 27 ms. Execution time 600 to 6300 ms.
> 
> ! Lacking any further information about the problem, we can't say.
> ! We can, however, point to
> ! https://wiki.postgresql.org/wiki/Slow_Query_Questions
> ! concerning how to ask this type of question effectively.
> 
> I strongly hope the data that I sent as followup will now 
> suffice Your expectations.

Your reported execution times don't match the time reported in the
EXPLAIN output...

The cause of the long execution time is clear:

The row count of the join between "places" (WHERE platz = 'WAEHR'),
"wpnames" and "places AS places_1" is underestimated by a factor of 10
(1 row instead of 10).

The nested loop join that is chosen as a consequence is now executed
10 times instead of the estimated 1 time, which is where almost all the
execution time is spent.

The question how to fix that is more complicated, and I cannot solve
it off-hand with a complicated query like that.

Setting "enable_nestloop = off" is as coarse as forcing "from_collapse = 1"
and will negatively impact other queries - if it helps at all.

You'll probably have to rewrite the query.
Sorry that I cannot be of more help.

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com


pgsql-performance by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: functions: VOLATILE performs better than STABLE
Next
From: David Rowley
Date:
Subject: Re: functions: VOLATILE performs better than STABLE