Re: remaining sql/json patches

On Nov 16, 2023, at 17:48, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Thu, Nov 16, 2023 at 2:11 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>> On 2023-11-15 22:00:41 +0900, Amit Langote wrote:
>>>> This causes a nontrivial increase in the size of the parser (~5% in an
>>>> optimized build here), I wonder if we can do better.
>>>
>>> Hmm, sorry if I sound ignorant but what do you mean by the parser here?
>>
>> gram.o, in an optimized build.
>>
>>> I can see that the byte-size of gram.o increases by 1.66% after the
>>> above additions (1.72% with previous versions).
>>
>> I'm not sure anymore how I measured it, but if you just looked at the total
>> file size, that might not show the full gain, because of debug symbols
>> etc. You can use the size command to look at just the code and data size.
>
> $ size /tmp/gram.*
> text data bss dec hex filename
> 661808 0 0 661808 a1930 /tmp/gram.o.unpatched
> 672800 0 0 672800 a4420 /tmp/gram.o.patched
>
> That's still a 1.66% increase in the code size:
>
> (672800 - 661808) / 661808 % = 1.66
>
> As for gram.c, the increase is a bit larger:
>
> $ ll /tmp/gram.*
> -rw-rw-r--. 1 amit amit 2605925 Nov 16 16:18 /tmp/gram.c.unpatched
> -rw-rw-r--. 1 amit amit 2709422 Nov 16 16:22 /tmp/gram.c.patched
>
> (2709422 - 2605925) / 2605925 % = 3.97
>
>>> I've also checked
>>> using log_parser_stats that there isn't much slowdown in the
>>> raw-parsing speed.
>>
>> What does "isn't much slowdown" mean in numbers?
>
> Sure, the benchmark I used measured the elapsed time (using
> log_parser_stats) of parsing a simple select statement (*) averaged
> over 10000 repetitions of the same query performed with `psql -c`:
>
> Unpatched: 0.000061 seconds
> Patched: 0.000061 seconds
>
> Here's a look at the perf:
>
> Unpatched:
> 0.59% [.] AllocSetAlloc
> 0.51% [.] hash_search_with_hash_value
> 0.47% [.] base_yyparse
>
> Patched:
> 0.63% [.] AllocSetAlloc
> 0.52% [.] hash_search_with_hash_value
> 0.44% [.] base_yyparse
>
> (*) select 1, 2, 3 from foo where a = 1
>
> Is there a more relevant benchmark I could use?

Thought I’d share a few more numbers I collected to analyze the parser size increase over releases.

* gram.o text bytes is from the output of `size gram.o`.
* compiled with -O3

version gram.o text bytes %change gram.c bytes %change

9.6 534010 - 2108984 -
10 582554 9.09 2258313 7.08
11 584596 0.35 2313475 2.44
12 590957 1.08 2341564 1.21
13 590381 -0.09 2357327 0.67
14 600707 1.74 2428841 3.03
15 633180 5.40 2495364 2.73
16 653464 3.20 2575269 3.20
17-sqljson 672800 2.95 2709422 3.97

So if we put SQL/JSON (including JSON_TABLE()) into 17, we end up with a gram.o 2.95% larger than v16, which granted is a somewhat larger bump, though also smaller than with some of recent releases.

> --

Thanks, Amit Langote
EDB: http://www.enterprisedb.com