| From: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
| Subject: | Re: Improve performance of pg_strtointNN functions |
| Date: | 2022-12-01 05:27:23 |
| Message-ID: | CAFBsxsGV6smh8R9fCfYwg50a-mJNkW49wygN5fPhtucTHUrrrg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Dec 1, 2022 at 6:42 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> I was thinking that we should likely apply this before doing the hex
> literals, which is the main focus of [1]. The reason being is so that
> that patch can immediately have faster conversions by allowing the
> compiler to use bit shifting instead of other means of multiplying by
> a power-of-2 number. I'm hoping this removes a barrier for Peter from
> the small gripe I raised on that thread about the patch having slower
> than required hex, octal and binary string parsing.
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.
--
John Naylor
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2022-12-01 05:38:05 | Re: Improve performance of pg_strtointNN functions |
| Previous Message | John Naylor | 2022-12-01 05:17:49 | Re: Prefetch the next tuple's memory during seqscans |