Re: Perfomance bug in v10

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Teodor Sigaev <teodor(at)postgrespro(dot)ru>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Perfomance bug in v10
Date: 2017-06-02 13:27:41
Message-ID: 10242.1496410061@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Teodor Sigaev <teodor(at)sigaev(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2017-06-02 13:37:27 Re: retry shm attach for windows (WAS: Re: OK, so culicidae is *still* broken)
Previous Message Thomas Munro 2017-06-02 13:20:43 Re: PG10 transition tables, wCTEs and multiple operations on the same table