Re: [PATCH] Use optimized single-datum tuplesort in ExecSort

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, James Coleman <jtc331(at)gmail(dot)com>
Subject: Re: [PATCH] Use optimized single-datum tuplesort in ExecSort
Date: 2021-07-06 11:48:51
Message-ID: CAEudQAq3d+vT-+U97AYsByAYLi+A61ixytga8PkbJNQ3S4ULzw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em ter., 6 de jul. de 2021 às 08:25, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
escreveu:

> Em ter., 6 de jul. de 2021 às 03:15, Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Nancarrow 2021-07-06 12:06:04 Re: Remove useless int64 range checks on BIGINT sequence MINVALUE/MAXVALUE values
Previous Message Dean Rasheed 2021-07-06 11:39:13 Re: [PATCH] expand the units that pg_size_pretty supports on output