Re: remaining sql/json patches

From: Andres Freund <andres(at)anarazel(dot)de>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, 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-15 17:11:19
Message-ID: 20231115171119.svvyzevtfvsqkxpx@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Thanks, this looks like a substantial improvement. I don't quite have time to
look right now, but I thought I'd answer one question below.

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.

> 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?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-11-15 17:12:07 Re: remaining sql/json patches
Previous Message Andres Freund 2023-11-15 16:57:37 Potential use-after-free in partion related code