Re: make add_paths_to_append_rel aware of startup cost

David Rowley <dgrowleyml@gmail.com>

From: David Rowley <dgrowleyml@gmail.com>
To: Andy Fan <zhihui.fan1213@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, Zhang Mingli <zmlpostgres@gmail.com>
Date: 2023-10-04T00:41:24Z
Lists: pgsql-hackers

Attachments

On Sun, 1 Oct 2023 at 21:26, Andy Fan <zhihui.fan1213@gmail.com> wrote:
>> But overall, I'm more inclined to just go with the more simple "add a
>> cheap unordered startup append path if considering cheap startup
>> plans" version. I see your latest patch does both. So, I'd suggest two
>> patches as I do see the merit in keeping this simple and cheap.  If we
>> can get the first part in and you still find cases where you're not
>> getting the most appropriate startup plan based on the tuple fraction,
>> then we can reconsider what extra complexity we should endure in the
>> code based on the example query where we've demonstrated the planner
>> is not choosing the best startup path appropriate to the given tuple
>> fraction.
>
> I think this is a fair point,  I agree that your first part is good enough to be
> committed first.   Actually I tried a lot to make a test case which can  prove
> the value of cheapest fractional cost but no gain so far:(

I've attached a patch with the same code as the previous patch but
this time including a regression test.

I see no reason to not commit this so if anyone feels differently
please let me know.

David

Commits

  1. Attempt to stabilize flapping regression test

  2. Consider cheap startup paths in add_paths_to_append_rel