Re: Names of run-time configuration parameters (was: Limiting the operations that client-side code can perform upon its database backend's artifacts)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Names of run-time configuration parameters (was: Limiting the operations that client-side code can perform upon its database backend's artifacts)
Дата
Msg-id 1072026.1664691717@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Names of run-time configuration parameters (was: Limiting the operations that client-side code can perform upon its database backend's artifacts)  (Bryn Llewellyn <bryn@yugabyte.com>)
Список pgsql-general
Bryn Llewellyn <bryn@yugabyte.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
creatingthe table only if it isn't. But I haven't done any timing tests. Is the "create… if not exists" so lightweight
whenthe 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



В списке pgsql-general по дате отправления:

Предыдущее
От: Bryn Llewellyn
Дата:
Сообщение: Re: Names of run-time configuration parameters (was: Limiting the operations that client-side code can perform upon its database backend's artifacts)
Следующее
От: jacktby jacktby
Дата:
Сообщение: C99's brain-dead