Re: Improve performance of pg_strtointNN functions

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Improve performance of pg_strtointNN functions
Date: 2022-12-01 09:55:12
Message-ID: CAEZATCUXb3ZFnr_76itrrwo97gZoNipxD2xW789ee2ZtmyUdDQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 1 Dec 2022 at 05:38, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Thu, 1 Dec 2022 at 18:27, John Naylor <john(dot)naylor(at)enterprisedb(dot)com> wrote:
> > I don't see why the non-decimal literal patch needs to be "immediately" faster? If doing this first leads to less code churn, that's another consideration, but you haven't made that argument.
>
> My view is that Peter wants to keep the code he's adding for the hex,
> octal and binary parsing as similar to the existing code as possible.
> I very much understand Peter's point of view on that. Consistency is
> good. However, if we commit the hex literals patch first, people might
> ask "why don't we use bit-wise operators to make the power-of-2 bases
> faster?", which seems like a very legitimate question. I asked it,
> anyway... On the other hand, if Peter adds the bit-wise operators
> then the problem of code inconsistency remains.
>
> As an alternative to those 2 options, I'm proposing we commit this
> first then the above dilemma disappears completely.
>
> If this was going to cause huge conflicts with Peter's patch then I
> might think differently. I feel like it's a fairly trivial task to
> rebase.
>
> If the consensus is that we should fix this afterwards, then I'm happy to delay.
>

I feel like it should be done afterwards, so that any performance
gains can be measured for all bases. Otherwise, we won't really know,
or have any record of, how much faster this was for other bases, or be
able to go back and test that.

Regards,
Dean

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2022-12-01 10:02:33 initdb: Refactor PG_CMD_PUTS loops
Previous Message Peter Eisentraut 2022-12-01 09:30:16 Re: pg_upgrade allows itself to be run twice