David Rowley <dgrowleyml@gmail.com> writes:
> On Sat, 4 Jan 2025 at 06:58, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> There is no value in forcing a sort of the subquery's output,
>> and the previous code didn't do so:
> The reason for the 2nd sort, (ignoring the invalidity of the pathkeys)
> is due to how build_setop_child_paths() tries sorting the
> cheapest_input_path. The problem is that the sorted path gets added
> to the same RelOptInfo as the cheapest_input_path so if add_path()
> sees they're fuzzily the same cost, the sorted has better pathkeys, so
> the actual cheapest path is thrown away. I think the reason this
> happens in this case is that there are just not that many rows to
> sort, and it's fairly expensive to get those rows.
Yeah, same conclusion Richard and I came to. It's not that big a
problem (aside from the validity issue) because this path would only
win if the sorting cost is estimated to be insignificant relative
to the subquery's other costs. So while it might be nice to improve
that in future, I'm not very concerned about it now.
regards, tom lane
