Re: [PATCH] Use optimized single-datum tuplesort in ExecSort - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: [PATCH] Use optimized single-datum tuplesort in ExecSort
Date
Msg-id CAEudQAq3d+vT-+U97AYsByAYLi+A61ixytga8PkbJNQ3S4ULzw@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Use optimized single-datum tuplesort in ExecSort  (Ranier Vilela <ranier.vf@gmail.com>)
List pgsql-hackers
Em ter., 6 de jul. de 2021 às 08:25, Ranier Vilela <ranier.vf@gmail.com> escreveu:
Em ter., 6 de jul. de 2021 às 03:15, Ronan Dunklau <ronan.dunklau@aiven.io> escreveu:
Hello,

While testing the patch "Add proper planner support for ORDER BY / DISTINCT
aggregates" [0] I discovered the performance penalty from adding a sort node
essentially came from not using the single-datum tuplesort optimization in
ExecSort (contrary to the sorting done in ExecAgg).

I originally proposed this patch as a companion in the same thread [1], but
following James suggestion I'm making a separate thread just for this as the
optimization is worthwhile independently of David's patch: it looks like we
can expect a 2x speedup on a "select a single ordered column" case.

The patch aimed to be as simple as possible: we only turn this optimization on
when the tuple being sorted has only one attribute, it is "byval" (so as not
to incur copies which would be hard to track in the execution tree) and
unbound (again, not having to deal with copying borrowed datum anywhere).

The attached patch is originally by me, with some cleanup by Ranier Vilela.
I'm sending Ranier's version here.
Nice Ronan.
But I think there is some confusion here.
The author is not you?

Just to clarify, at Commitfest, it was supposed to be the other way around.
You as an author and David as a reviewer.
I'll put myself as a reviewer too.
Sorry David, my mistake.
I confused the numbers (id) of Commitfest.

regards,
Ranier Vilela

pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: [PATCH] expand the units that pg_size_pretty supports on output
Next
From: Greg Nancarrow
Date:
Subject: Re: Remove useless int64 range checks on BIGINT sequence MINVALUE/MAXVALUE values