Re: [HACKERS] Perfomance bug in v10
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Perfomance bug in v10 |
Дата | |
Msg-id | 10242.1496410061@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Perfomance bug in v10 (Teodor Sigaev <teodor@sigaev.ru>) |
Ответы |
Re: [HACKERS] Perfomance bug in v10
|
Список | 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 по дате отправления: