Re: Ordered Partitioned Table Scans - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Ordered Partitioned Table Scans
Date
Msg-id 5709.1553272839@sss.pgh.pa.us
Whole thread Raw
In response to Re: Ordered Partitioned Table Scans  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Ordered Partitioned Table Scans
Re: Ordered Partitioned Table Scans
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Ordered Partitioned Table Scans
Next
From: Andres Freund
Date:
Subject: Re: Enable data checksums by default