Re: Considering fractional paths in Append node

On 10/18/24 07:54, Andy Fan wrote:
> Nikita Malakhov <hukutoc@gmail.com> writes:
>> The effect is easily seen in one of standard PG tests:
> """
> I think that things might work out better if we redefined the startup
> cost as "estimated cost to retrieve the first tuple", rather than its
> current very-squishy definition as "cost to initialize the scan".
> """
> The above statement makes me confused. If we take the startup cost as
> cost to retrieve cost for the first tuple, we can do the below quick hack,
Promising way to go. Of course even in that case IndexScan usually gives 
way to SeqScan (because of the additional heap fetch). And only 
IndexOnlyScan may overcome it. Moreover, SeqScan first tuple cost is 
contradictory issue - who knows, how much tuples it will filter before 
the first tuple will be produced?

> 
> Looks we still have some other stuff to do, but we have seen the desired
> plan has a closer cost to estimated best plan than before.
But our patch is about some different stuff: adding one more Append 
strategy (and, as I realised recently, one promising MergeAppend too) we 
give a chance upper fraction-friendly node to decide which plan is 
better. Right now, AFAIK, only LIMIT node can profit from that (maybe 
IncrementalSort if we include MergeAppend). But it may open a door to 
improve other nodes too.

-- 
regards, Andrei Lepikhov