Re: Should from_collapse be switched off? (queries 10 times faster)

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Peter <pmc(at)citylink(dot)dinoex(dot)sub(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: Should from_collapse be switched off? (queries 10 times faster)
Date: 2018-03-25 05:12:08
Message-ID: 1521954728.2350.24.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message David Rowley 2018-03-25 12:24:00 Re: functions: VOLATILE performs better than STABLE
Previous Message Laurenz Albe 2018-03-25 05:00:43 Re: functions: VOLATILE performs better than STABLE