Re: Improve performance of pg_strtointNN functions

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Improve performance of pg_strtointNN functions
Дата
Msg-id CAApHDvrtc4fW18vChjkdFxreNv0zrxeKk42e1US3skGSwwYQ9g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Improve performance of pg_strtointNN functions  (John Naylor <john.naylor@enterprisedb.com>)
Ответы Re: Improve performance of pg_strtointNN functions  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Re: Improve performance of pg_strtointNN functions  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список pgsql-hackers
On Thu, 1 Dec 2022 at 18:27, John Naylor <john.naylor@enterprisedb.com> wrote:
> I don't see why the non-decimal literal patch needs to be "immediately" faster? If doing this first leads to less
codechurn, 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.

David



В списке pgsql-hackers по дате отправления:

Предыдущее
От: John Naylor
Дата:
Сообщение: Re: Improve performance of pg_strtointNN functions
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Perform streaming logical transactions by background workers and parallel apply