From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bryn Llewellyn <bryn(at)yugabyte(dot)com> |
Cc: | "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at>, pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Names of run-time configuration parameters (was: Limiting the operations that client-side code can perform upon its database backend's artifacts) |
Date: | 2022-10-02 06:21:57 |
Message-ID: | 1072026.1664691717@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Bryn Llewellyn <bryn(at)yugabyte(dot)com> writes:
> I've seen this pattern in use:
> create temp table if not exists pg_temp.flag(val boolean not null) on commit delete rows;
> insert into pg_temp.flag(val) values(true);
> But doing a DDL before every use of the session-state representation felt heavier than assuming that it's there and creating the table only if it isn't. But I haven't done any timing tests. Is the "create… if not exists" so lightweight when the to-be-created object does exist that I'm fussing over nothing?
Fair question. My gut feeling is that the subtransaction created by the
BEGIN ... EXCEPTION construct is more expensive than a no-op CREATE
IF NOT EXISTS. I've not measured it though; and I'm pretty sure that
the answer would vary depending on how often you expect the code to fall
through versus needing to create the table.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | jacktby jacktby | 2022-10-02 11:54:06 | C99's brain-dead |
Previous Message | Bryn Llewellyn | 2022-10-02 05:33:57 | Re: Names of run-time configuration parameters (was: Limiting the operations that client-side code can perform upon its database backend's artifacts) |