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

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>, James Coleman <jtc331(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: [PATCH] Use optimized single-datum tuplesort in ExecSort
Date: 2021-07-15 00:10:18
Message-ID: CAEudQAqAP09d8K8s6XzXkcW5LKcTfgxAgAoVZCHpzwiGH_ddVw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em qua., 14 de jul. de 2021 às 20:43, David Rowley <dgrowleyml(at)gmail(dot)com>
escreveu:

> On Thu, 15 Jul 2021 at 05:55, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:
> > I repeated (3 times) the benchmark with v8 here,
> > and the results were not good.
>
> Do you have any good theories on why the additional branching that's
> done in v7b vs v8 might cause it to run faster?

Branch Predictions works with *more* probable path,
otherwise a penalty occurs and the cpu must revert the results.

In this case it seems to me that most of the time, tuplesort is the path.
So as it is tested if it is *datumSort* and the *prediction* fails,
the cpu has more work to reverse the wrong path.

To help the branch, test a more probable case first, anywhere.
if, switch, etc.

Another gain is the local variable tupleSort, which is obviously faster
than node.

regards,
Ranier Vilela

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2021-07-15 00:20:58 Re: [PATCH] Use optimized single-datum tuplesort in ExecSort
Previous Message Alvaro Herrera 2021-07-14 23:45:23 Re: CREATE TABLE .. PARTITION OF fails to preserve tgenabled for inherited row triggers