From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: appendBinaryStringInfo stuff |
Date: | 2022-12-22 07:48:39 |
Message-ID: | CAApHDvpTZjQD=341ThPO95u1nhZ+nmeXWJtwrXT3i2rU45SscQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 20 Dec 2022 at 11:26, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> It would be good to see some measurements to find out how much adding
> the strlen calls back in would cost us.
I tried this out. I'm not pretending I found the best test which
highlights how much the performance will change in a real-world case.
I just wanted to try to get an indication of if changing jsonb's
output function to make more use of appendStringInfoString instead of
appendBinaryStringInfo is likely to affect performance.
Also, in test 2, I picked a use case that makes quite a bit of use of
appendStringInfoString already and checked if inlining that function
would help improve things. I imagine test 2 really is not
bottlenecked on appendStringInfoString enough to get a true idea of
how much inlining appendStringInfoString could really help (spoiler,
it helps quite a bit)
Test 1: See if using appendStringInfoString instead of
appendBinaryStringInfo hinders jsonb output performance.
setup:
create table jb (j jsonb);
insert into jb select row_to_json(pg_class) from pg_class;
vacuum freeze analyze jb;
bench.sql:
select sum(length(j::text)) from jb;
master (@3f28bd73):
$ pgbench -n -T 60 -f bench.sql -M prepared postgres | grep latency
latency average = 1.896 ms
latency average = 1.885 ms
latency average = 1.899 ms
22.57% postgres [.] escape_json
21.83% postgres [.] pg_utf_mblen
9.23% postgres [.] JsonbIteratorNext.part.0
7.12% postgres [.] AllocSetAlloc
4.07% postgres [.] pg_mbstrlen_with_len
3.71% postgres [.] JsonbToCStringWorker
3.70% postgres [.] fillJsonbValue
3.17% postgres [.] appendBinaryStringInfo
2.95% postgres [.] enlargeStringInfo
2.09% postgres [.] jsonb_put_escaped_value
1.89% postgres [.] palloc
master + 0001-Use-appendStringInfoString-instead-of-appendBinarySt.patch
$ pgbench -n -T 60 -f bench.sql -M prepared postgres | grep latency
latency average = 1.912 ms
latency average = 1.912 ms
latency average = 1.912 ms (~1% slower)
22.38% postgres [.] escape_json
21.98% postgres [.] pg_utf_mblen
9.07% postgres [.] JsonbIteratorNext.part.0
5.93% postgres [.] AllocSetAlloc
4.11% postgres [.] pg_mbstrlen_with_len
3.87% postgres [.] fillJsonbValue
3.66% postgres [.] JsonbToCStringWorker
2.28% postgres [.] enlargeStringInfo
2.15% postgres [.] appendStringInfoString
1.98% postgres [.] jsonb_put_escaped_value
1.92% postgres [.] palloc
1.58% postgres [.] appendBinaryStringInfo
1.42% postgres [.] pnstrdup
Test 2: Test if inlining appendStringInfoString helps
bench.sql:
select sum(length(pg_get_ruledef(oid))) from pg_rewrite;
master (@3f28bd73):
$ pgbench -n -T 60 -f bench.sql postgres | grep latency
latency average = 16.355 ms
latency average = 16.290 ms
latency average = 16.303 ms
static inline appendStringInfoString
$ pgbench -n -T 60 -f bench.sql postgres | grep latency
latency average = 15.690 ms
latency average = 15.575 ms
latency average = 15.604 ms (~4.4% faster)
David
From | Date | Subject | |
---|---|---|---|
Next Message | Drouvot, Bertrand | 2022-12-22 07:50:34 | Re: Minimal logical decoding on standbys |
Previous Message | Kyotaro Horiguchi | 2022-12-22 07:45:07 | Re: Force streaming every change in logical decoding |