Re: Incorrect cost for MergeAppend

On Mon, Jan 29, 2024 at 6:11 PM Alexander Kuzmenkov
<akuzmenkov(at)timescale(dot)com> wrote:
>
> Hello hackers,
>
> While investigating some query plans, I noticed some code that seems
> to be wrong: when create_merge_append_path() estimates the cost of
> sorting an input, it calls cost_sort() passing subpath->parent->tuples
> as the number of tuples. Shouldn't it use subpath->parent->rows or
> even subpath->rows instead? The `tuples` variable doesn't account for
> the filters on the relation, so this leads to incorrect cost estimates
> when there are highly selective filters, and Sort + Append is chosen
> instead of MergeAppend.

All other callers of cost_sort() except plan_cluster_use_sort() are
using rows instead of tuples. Even plan_cluster_use_sort() has
rel->rows = rel->tuples, it's actually passing rows. So agree with
your suggestion. However a test will be good since this code is quite
old.

--
Best Wishes,
Ashutosh Bapat