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

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Downsides of liberally using CREATE TEMP TABLE ... ON COMMIT DROP
Дата
Msg-id CAKFQuwbu-cO8kC6LhFXmuPYMH+3UNXBHNT0YHOV6L6v-RvYxdQ@mail.gmail.com
обсуждение исходный текст
Ответ на Downsides of liberally using CREATE TEMP TABLE ... ON COMMIT DROP  (Ryan Murphy <ryanfmurphy@gmail.com>)
Ответы Re: Downsides of liberally using CREATE TEMP TABLE ... ON COMMIT DROP  (Ryan Murphy <ryanfmurphy@gmail.com>)
Список pgsql-general
On Sunday, January 28, 2018, Ryan Murphy <ryanfmurphy@gmail.com> wrote:
Hello,

I heard at a PostgreSQL talk that you should not liberally create temp tables in the course of frequently-used functions etc, because (roughly) you're using up some of the same resources that you for your regular tables.

Is this true?  Is there an important reason not to have e.g. a plpgsql function that uses a temp table?  What are the specific problems if I do this?  Is the problem ameliorated if I add ON COMMIT DROP?

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.

The way most temp tables are used on commit drop likely has little impact on this, but the specific usage pattern matters a great deal in answering the question.

David J.

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

Предыдущее
От: Ryan Murphy
Дата:
Сообщение: Downsides of liberally using CREATE TEMP TABLE ... ON COMMIT DROP
Следующее
От: Ryan Murphy
Дата:
Сообщение: Re: Downsides of liberally using CREATE TEMP TABLE ... ON COMMIT DROP