Re: remaining sql/json patches

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: John Naylor <johncnaylorls(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Amit Langote <amitlangote09(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, jian he <jian(dot)universality(at)gmail(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: remaining sql/json patches
Date: 2023-11-29 17:03:04
Message-ID: 39f52aa5-b923-4889-f047-ae61551d751a@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2023-11-28 Tu 20:58, Andrew Dunstan wrote:
>
> On 2023-11-28 Tu 19:32, Tom Lane wrote:
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>> Cool, I took this and ran with it a bit. (See attached) Here are
>>> comparative timings for 1000 iterations parsing most of the
>>> information_schema.sql, all the way back to 9.3:
>>> ...
>>> ==== REL_15_STABLE ====
>>> Time: 3372.491 ms (00:03.372)
>>> ==== REL_16_STABLE ====
>>> Time: 1654.056 ms (00:01.654)
>>> ==== HEAD ====
>>> Time: 1614.949 ms (00:01.615)
>>> This is fairly repeatable.
>> These results astonished me, because I didn't recall us having done
>> anything that'd be likely to double the speed of the raw parser.
>> So I set out to replicate them, intending to bisect to find where
>> the change happened.  And ... I can't replicate them.  What I got
>> is essentially level performance from HEAD back to d10b19e22
>> (Stamp HEAD as 14devel):
>>
>> HEAD: 3742.544 ms
>> d31d30973a (16 stamp): 3871.441 ms
>> 596b5af1d (15 stamp): 3759.319 ms
>> d10b19e22 (14 stamp): 3730.834 ms
>>
>> The run-to-run variation is a couple percent, which means that
>> these differences are down in the noise.  This is using your
>> test code from github (but with 5000 iterations not 1000).
>> Builds are pretty vanilla with asserts off, on an M1 MacBook Pro.
>> The bison version might matter here: it's 3.8.2 from MacPorts.
>>
>> I wondered if you'd tested assert-enabled builds, but there
>> doesn't seem to be much variation with that turned on either.
>>
>> So I'm now a bit baffled.  Can you provide more color on what
>> your test setup is?
>
>
> *sigh* yes, you're right. I inadvertently used a setup that used meson
> for building REL16_STABLE and HEAD. When I switch it to autoconf I get
> results that are similar to the earlier branches:
>
>
> ==== REL_16_STABLE ====
> Time: 3401.625 ms (00:03.402)
> ==== HEAD ====
> Time: 3419.088 ms (00:03.419)
>
>
> It's not clear to me why that should be. I didn't have assertions
> enabled anywhere. It's the same version of bison, same compiler
> throughout. Maybe meson sets a higher level of optimization? It
> shouldn't really matter, ISTM.

OK, with completely vanilla autoconf builds, doing 5000 iterations, here
are the timings I get, including a test with Amit's latest published
patches (with a small fixup due to bitrot).

Essentially, with the patches applied it's very slightly slower than
master, about the same as release 16, faster than everything earlier.
And we hope to improve the grammar impact of the JSON_TABLE piece before
we're done.

==== REL_11_STABLE ====
Time: 10381.814 ms (00:10.382)
==== REL_12_STABLE ====
Time: 8151.213 ms (00:08.151)
==== REL_13_STABLE ====
Time: 7774.034 ms (00:07.774)
==== REL_14_STABLE ====
Time: 7911.005 ms (00:07.911)
==== REL_15_STABLE ====
Time: 7868.483 ms (00:07.868)
==== REL_16_STABLE ====
Time: 7729.359 ms (00:07.729)
==== master ====
Time: 7615.815 ms (00:07.616)
==== sqljson ====
Time: 7715.652 ms (00:07.716)

Bottom line: I don't think grammar slowdown is a reason to be concerned
about these patches.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2023-11-29 17:15:26 add AVX2 support to simd.h
Previous Message Alvaro Herrera 2023-11-29 16:58:22 Re: SSL tests fail on OpenSSL v3.2.0