Re: Speedup usages of pg_*toa() functions

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Speedup usages of pg_*toa() functions
Date: 2020-06-11 03:36:48
Message-ID: CAApHDvp04HAxSfi3MZUp2kYsiOjhbv-d3kZorS1v_Wj0uHwv8w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 10 Jun 2020 at 11:57, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Tue, 9 Jun 2020 at 22:08, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> wrote:
> >
> > >>>>> "David" == David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> >
> > David> This allows us to speed up a few cases. int2vectorout() should
> > David> be faster and int8out() becomes a bit faster if we get rid of
> > David> the strdup() call and replace it with a palloc()/memcpy() call.
> >
> > What about removing the memcpy entirely? I don't think we save anything
> > much useful here by pallocing the exact length, rather than doing what
> > int4out does and palloc a fixed size and convert the int directly into
> > it.
>
> The attached 0001 patch does this.

Pending any objections, I'd like to push both of these patches in the
next few days to master.

Anyone object to changing the signature of these functions in 0002, or
have concerns about allocating the maximum memory that we might
require in int8out()?

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2020-06-11 04:03:17 Re: Parallel Seq Scan vs kernel read ahead
Previous Message Amit Kapila 2020-06-11 03:30:22 Re: Resetting spilled txn statistics in pg_stat_replication