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 01:58:41
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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.



Andrew Dunstan

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2023-11-29 02:03:00 RE: [PoC] pg_upgrade: allow to upgrade publisher node
Previous Message jian he 2023-11-29 01:37:55 Re: [PATCH] ltree hash functions