Horton

Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size

Jonathan S. Katz <jkatz@postgresql.org>

View thread View on postgr.es
From: "Jonathan S. Katz" <jkatz@postgresql.org>
To: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, Amit Langote <amitlangote09@gmail.com>, David Rowley <dgrowleyml@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Michael Paquier <michael@paquier.xyz>, John Naylor <john.naylor@enterprisedb.com>, Peter Geoghegan <pg@bowt.ie>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Nikita Glukhov <n.gluhov@postgrespro.ru>
Date: 2022-08-09T19:50:36Z
Lists: pgsql-hackers 
On 8/9/22 3:22 PM, Andres Freund wrote:
> Hi,
> 
> On 2022-08-09 15:17:44 -0400, Tom Lane wrote:
>> We have delayed releases for $COOL_FEATURE in the past, and I think
>> our batting average on that is still .000: not once has it worked out
>> well.
> 
> I think it semi worked when jsonb (?) first went in - it took a while and a
> lot of effort from a lot of people, but in the end we made it work, and it was
> a success from our user's perspectives, I think. 

Yeah, this was the example I was thinking of. To continue with the 
baseball analogy, it was a home-run from a PR perspective, and I can say 
as a power user at the time, the 9.4 JSONB representation worked well 
for my use case. Certainly newer functionality has made JSON easier to 
work with in PG.

(I can't remember what the 9.5 hold up was).

The cases where we either delayed/punted on $COOL_FEATURE that cause me 
concern are the ones where we say "OK, well fix this in the next 
release" and we are then waiting, 2, 3, 4 releases for the work to be 
completed. And to be clear, I'm thinking of this as "known issues" vs. 
"iterating towards the whole solution".

> OTOH, it's not a great sign  this is around json again...

Yeah, I was thinking about that too.

Per Andres comment upthread, let's open a new thread to discuss the 
SQL/JSON + v15 topic to improve visibility and get more feedback. I can 
do that shortly.

We can continue with the technical discussion in here.

Jonathan

Commits

  1. JSON_TABLE: Add support for NESTED paths and columns

  2. Add basic JSON_TABLE() functionality

  3. Add SQL/JSON query functions

  4. Add soft error handling to some expression nodes

  5. Adjust populate_record_field() to handle errors softly

  6. Refactor code used by jsonpath executor to fetch variables

  7. Add more SQL/JSON constructor functions

  8. SQL/JSON: support the IS JSON predicate

  9. SQL/JSON: add standard JSON constructor functions

  10. Add static assertion ensuring sizeof(ExprEvalStep) <= 64 bytes

  11. Remove size increase in ExprEvalStep caused by hashed saops

  12. pgstat: reduce timer overhead by leaving timer running.

  13. expression eval: Fix EEOP_JSON_CONSTRUCTOR and EEOP_JSONEXPR size.

  14. SQL/JSON query functions

  15. Speedup ScalarArrayOpExpr evaluation