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
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 |