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:(
