From: | Andy Fan <zhihuifan1213(at)163(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Make printtup a bit faster |
Date: | 2024-08-30 05:00:50 |
Message-ID: | 87v7zihaf1.fsf@163.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Fri, 30 Aug 2024 at 03:33, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> David Rowley <dgrowleyml(at)gmail(dot)com> writes:
>> > [ redesign I/O function APIs ]
>> > I had planned to work on this for PG18, but I'd be happy for some
>> > assistance if you're willing.
>>
>> I'm skeptical that such a thing will ever be practical. To avoid
>> breaking un-converted data types, all the call sites would have to
>> support both old and new APIs. To avoid breaking non-core callers,
>> all the I/O functions would have to support both old and new APIs.
>> That probably adds enough overhead to negate whatever benefit you'd
>> get.
>
> So, we currently return cstrings in our output functions. Let's take
> jsonb_out() as an example, to build that cstring, we make a *new*
> StringInfoData on *every call* inside JsonbToCStringWorker(). That
> gives you 1024 bytes before you need to enlarge it. However, it's
> maybe not all bad as we have some size estimations there to call
> enlargeStringInfo(), only that's a bit wasteful as it does a
> repalloc() which memcpys the freshly allocated 1024 bytes allocated in
> initStringInfo() when it doesn't yet contain any data. After
> jsonb_out() has returned and we have the cstring, only we forgot the
> length of the string, so most places will immediately call strlen() or
> do that indirectly via appendStringInfoString(). For larger JSON
> documents, that'll likely require pulling cachelines back into L1
> again. I don't know how modern CPU cacheline eviction works, but if it
> was as simple as FIFO then the strlen() would flush all those
> cachelines only for memcpy() to have to read them back again for
> output strings larger than L1.
The attached is PoC of this idea, not matter which method are adopted
(rewrite all the outfunction or a optional print function), I think the
benefit will be similar. In the blew test case, it shows us 10%+
improvements. (0.134ms vs 0.110ms)
create table demo as select oid as oid1, relname::text as text1, relam,
relname::text as text2 from pg_class;
pgbench:
select * from demo;
--
Best Regards
Andy Fan
Attachment | Content-Type | Size |
---|---|---|
v20240830-0001-Avoiding-some-memcpy-strlen-palloc-in-prin.patch | text/x-diff | 5.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2024-08-30 05:19:05 | Re: [PATCH] Enable using llvm jitlink as an alternative llvm jit linker of old Rtdyld. |
Previous Message | Pavel Stehule | 2024-08-30 04:46:12 | Re: [PATCH] Add CANONICAL option to xmlserialize |