Re: Make printtup a bit faster

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Andy Fan <zhihuifan1213(at)163(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Make printtup a bit faster
Date: 2024-08-30 01:13:37
Message-ID: CAApHDvrQPQsO0FVP+4VC61+F3pqt7gUwnK1_ODmd_JL-GddZ3A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 30 Aug 2024 at 13:04, Andy Fan <zhihuifan1213(at)163(dot)com> wrote:
>
> David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> > If there's anywhere we call output functions
> > where the resulting value isn't directly appended to a StringInfo,
> > then we could just use a temporary StringInfo to obtain the cstring
> > and its length.
>
> I think this is true, but it requests some caller's code change.

Yeah, calling code would need to be changed to take advantage of the
new API, however, the differences in which types support which API
could be hidden inside OutputFunctionCall(). That function could just
fake up a StringInfo for any types that only support the old cstring
API. That means we don't need to add handling for both cases
everywhere we need to call the output function. It's possible that
could make some operations slightly slower when only the old API is
available, but then maybe not as we do now have read-only StringInfos.
Maybe the StringInfoData.data field could just be set to point to the
given cstring using initReadOnlyStringInfo() rather than doing
appendBinaryStringInfo() onto yet another buffer for the old API.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andy Fan 2024-08-30 01:34:34 Re: Make printtup a bit faster
Previous Message Andy Fan 2024-08-30 01:04:18 Re: Make printtup a bit faster