Re: [HACKERS] Perfomance bug in v10 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Perfomance bug in v10
Date
Msg-id 10242.1496410061@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Perfomance bug in v10  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: [HACKERS] Perfomance bug in v10  (Claudio Freire <klaussfreire@gmail.com>)
List pgsql-hackers
Teodor Sigaev <teodor@sigaev.ru> writes:
>> Teodor, could you check if this patch fixes your real-world problem?

> It works fine with original query, thank you. But some other query slowdowns for
> ~10% (9 secs vs 10 secs). Look at following part of plans of huge query:
> ...
> As you said, it removes Materialize node, although it's useful here.

Meh.  If it's expecting only one outer row, it shouldn't be using a
Materialize on the inner side, period.  That's not sane per the cost
model.  You haven't shown us enough to guess why the rowcount estimates
are so far off reality in this query, but I don't think it's the fault
of this patch if the result is slightly slower given that much error.

Most likely, the answer for your real-world problem is "you need to
ANALYZE before running the query".
        regards, tom lane



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [HACKERS] PG10 transition tables, wCTEs and multiple operations on the same table
Next
From: Amit Kapila
Date:
Subject: Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidaeis *still* broken)