Re: remaining sql/json patches - Mailing list pgsql-hackers

From John Naylor
Subject Re: remaining sql/json patches
Date
Msg-id CANWCAZaF0a+GCqJN+DP5FwNpDiVt4758Fi-UWn98FunMLaw1EQ@mail.gmail.com
Whole thread Raw
In response to Re: remaining sql/json patches  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: remaining sql/json patches
List pgsql-hackers
On Mon, Nov 27, 2023 at 8:57 PM Andrew Dunstan <andrew@dunslane.net> wrote:
> Interesting. But inferring a speed effect from such changes is
> difficult. I don't have a good idea about measuring parser speed, but a
> tool to do that would be useful. Amit has made a start on such
> measurements, but it's only a start. I'd prefer to have evidence rather
> than speculation.

Tom shared this test a while back, and that's the one I've used in the
past. The downside for a micro-benchmark like that is that it can
monopolize the CPU cache. Cache misses in real world queries are
likely much more dominant.

https://www.postgresql.org/message-id/14616.1558560331@sss.pgh.pa.us

Aside on the relevance of parser speed: I've seen customers
successfully lower their monthly cloud bills by moving away from
prepared statements, allowing smaller-memory instances.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: New instability in stats regression test
Next
From: Shubham Khanna
Date:
Subject: Re: Improve tab completion for ALTER DEFAULT PRIVILEGE and ALTER TABLE