Re: Make printtup a bit faster - Mailing list pgsql-hackers

From Andy Fan
Subject Re: Make printtup a bit faster
Date
Msg-id 8734mmiyj9.fsf@163.com
Whole thread Raw
In response to Make printtup a bit faster  (Andy Fan <zhihuifan1213@163.com>)
List pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes:

> On Fri, 30 Aug 2024 at 13:04, Andy Fan <zhihuifan1213@163.com> wrote:
>>
>> David Rowley <dgrowleyml@gmail.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.

We can do this, then the printtup case (stands for some performance
crital path) still need to change discard OutputFunctionCall() since it
uses the fake StringInfo then a memcpy is needed again IIUC.

Besides above, my major concerns about your proposal need to change [all
the type's outfunction at once] which is too aggresive for me. In the
fresh setup without any extension is created, "SELECT count(*) FROM
pg_type" returns 627 already, So other piece of my previous reply is 
more important to me.  

It is great that both of us feeling the current stategy is not good for
performance:) 

-- 
Best Regards
Andy Fan




pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Make printtup a bit faster
Next
From: Alexander Lakhin
Date:
Subject: Re: configure failures on chipmunk