Re: SQL/JSON features for v15

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Michael Paquier <michael(at)paquier(dot)xyz>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>
Subject: Re: SQL/JSON features for v15
Date: 2022-08-16 13:55:14
Message-ID: CA+TgmobLe0NXWXD2R=7ZBbb23Sd0Hszq0NrNbzGDUQoHQYQ0Jw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 15, 2022 at 6:39 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I don't think it's sane from a performance view to start a subtransaction for
> every coercion, particularly because most coercion paths will never trigger an
> error, leaving things like out-of-memory or interrupts aside. And those are
> re-thrown by ExecEvalJsonExprSubtrans(). A quick and dirty benchmark shows
> ERROR ON ERROR nearly 2xing speed. I'm worried about the system impact of
> using subtransactions this heavily, it's not exactly the best performing
> system - the only reason it's kind of ok here is that it's going to be very
> rare to allocate a subxid, I think.

I agree. It kinda surprises me that we thought it was OK to commit
something that uses that many subtransactions. I feel like that's
going to cause people to hose themselves in ways that we can't really
do anything about. Like they'll test it out, it will work, and then
when they put it into production, they'll have constant wraparound
issues for which the only real solution is to not use the feature they
relied on to build the application.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christoph Berg 2022-08-16 13:56:45 Re: pg_receivewal and SIGTERM
Previous Message Tom Lane 2022-08-16 13:50:23 Re: Move NON_EXEC_STATIC from c.h