Re: Downsides of liberally using CREATE TEMP TABLE ... ON COMMIT DROP

Поиск
Список
Период
Сортировка
От Ryan Murphy
Тема Re: Downsides of liberally using CREATE TEMP TABLE ... ON COMMIT DROP
Дата
Msg-id CAHeEsBfRXy15hQVUi_3BP=6mjr46pc+SDwvxpGn5So3_wheZJQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Downsides of liberally using CREATE TEMP TABLE ... ON COMMIT DROP  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: Downsides of liberally using CREATE TEMP TABLE ... ON COMMIT DROP  (Andy Colson <andy@squeakycode.net>)
Список pgsql-general
I believe the main, and maybe only, concern is the bloating of the system catalog tables since you are constantly adding and removing records.  Yes, they will be vacuumed but vacuuming and bloat on catalog tables slows every single query down to some, degree since every query has to lookup its objects is those catalogs.  Though caching probably alleviates some of that

Yes, that's exactly the concern I heard, thanks for reminding me.

If I want to e.g. temporarily store a "setof records" or a "table" result in a variable as part of a calculation in a plpgsql function, do I have any other option than CREATE TEMPORARY TABLE?  It didn't seem to work when I DECLAREd a variable of type "setof table_name" or "setof table_name%rowtype", and then SELECT INTO it.

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

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: Downsides of liberally using CREATE TEMP TABLE ... ON COMMIT DROP
Следующее
От: Andy Colson
Дата:
Сообщение: Re: Downsides of liberally using CREATE TEMP TABLE ... ON COMMIT DROP