Re: [HACKERS] Perfomance bug in v10

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Perfomance bug in v10
Дата
Msg-id 20748.1496415768@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Perfomance bug in v10  (Teodor Sigaev <teodor@sigaev.ru>)
Ответы Re: [HACKERS] Perfomance bug in v10  (Teodor Sigaev <teodor@sigaev.ru>)
Список pgsql-hackers
Teodor Sigaev <teodor@sigaev.ru> writes:
>> There were old threads about considering a risk factor when estimating
>> plans, and I'm thinking this issue is the planner failing to do
>> exactly that.

> I'm afraid it's tool late for v10

Yeah, we're surely not opening that can of worms for v10.  Right now
we have to be content with avoiding regressions from 9.6.

BTW, was the larger query plan that you showed (with a Materialize node)
generated by 9.6, or v10 HEAD?  Because I would be surprised if 9.6 did
it.  But this bug could well cause HEAD to insert Materialize nodes in
surprising places, because it would have the effect of making a nestloop
with a single row expected from the outer rel look cheaper with a
Materialize on the inner rel than without.

(Actually I guess 9.6 would have done that too, but only for semi/anti
join cases, limiting the visibility of the bug.)
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: [HACKERS] Perfomance bug in v10
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling fromrw-conflict tracking in serializable transactions