"=?utf-8?B?Q2hlbmh1aU1v?=" <[email protected]> writes:
> The attached POC therefore also postpones individually cheap expressions when:
> total_expression_cost * (input_rows - limit_tuples)
> >
> 10 * cpu_operator_cost * limit_tuples
> This roughly compares the expression work avoided on discarded rows with a
> conservative threshold proportional to the rows that survive the Sort.
So ... the problem with proposals like this is that our cost estimates
for scalar expressions are pretty nearly useless, rendering planning
decisions that are strongly dependent on them mostly junk. See for
example the sad fate of commit db0d67db2, eventually reverted at
f4c7c410e. (Read the commit message for f4c7c410e and the linked
email discussion.) I'm not so worried about cost estimates where
expression costs are only part of the total, but this proposal seems
completely dependent on expression costs, so I think it's likely to
be mostly garbage-in-garbage-out. What can we do to have more
confidence in the choice?
regards, tom lane
