Re: Ordered Partitioned Table Scans

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Ordered Partitioned Table Scans
Дата
Msg-id 5709.1553272839@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Ordered Partitioned Table Scans  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Ordered Partitioned Table Scans
Re: Ordered Partitioned Table Scans
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Mar 22, 2019 at 11:56 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> In cases where, say, the first child requires no sort but also doesn't
>> emit very many rows, while the second child requires an expensive sort,
>> the planner will have a ridiculously optimistic opinion of the cost of
>> fetching slightly more rows than are available from the first child.
>> This might lead it to wrongly choose a merge join over a hash for example.

> I think this is very much a valid point, especially in view of the
> fact that we already choose supposedly fast-start plans too often.  I
> don't know whether it's a death sentence for this patch, but it should
> at least make us stop and think hard.

BTW, another thing we could possibly do to answer this objection is to
give the ordered-Append node an artificially pessimistic startup cost,
such as the sum or the max of its children's startup costs.  That's
pretty ugly and unprincipled, but maybe it's better than not having the
ability to generate the plan shape at all?

            regards, tom lane


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Ordered Partitioned Table Scans
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Enable data checksums by default