Re: a large LIMIT makes some sorts slower

Hi Tatsuya,

> On Aug 2, 2026, at 19:08, Tatsuya Kawata <kawatatatsuya0913(at)gmail(dot)com> wrote:
>
> It looks like tuples arriving after the switch to the heap are each
> compared against the heap root once and mostly discarded right there,
> so the premise behind abbreviation -- pay the conversion cost once and
> reuse it across many comparisons -- doesn't hold, and we end up
> dutifully converting tuples that never pay for themselves.

Thank you for digging into this and for sharing both the measurements
and the sample patch. Your analysis is very helpful and gave me another
way to think about the problem.

It made me wonder whether there might be another way to separate
admission from heap maintenance. I tried a small alternative that
retains abbreviated leading keys in the heap, while deferring
abbreviation of each incoming tuple until admission is decided. The
incoming tuple's authoritative leading key is first compared with a
cached authoritative leading key for the heap root. Rejected tuples
never pass through the abbreviation converter; eligible survivors are
abbreviated just before entering the heap.

Two follow-ups remain. For performance robustness, a bounded heap that
retains abbreviated keys should continue evaluating whether abbreviation
remains worthwhile for tuples admitted to the heap. Also, when the
authoritative leading keys compare equal, the current tiebreak path
starts again at the leading key before considering any additional sort
keys. Neither affects the basic idea, but both would need to be
addressed if this direction turns out to be useful.

The attached patch is only intended to illustrate another possible
direction, not to claim that it is the right solution. In the cases I
have tested so far, its results are broadly in line with yours. If the
approach seems reasonable, I would like to work through more concrete
examples, compare both approaches across a wider range of scenarios, and
address the two follow-ups above.

Thanks again for sharing this.

--
Best regards,
Chengpeng Yan