| From: | Ryan Murphy <ryanfmurphy(at)gmail(dot)com> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Downsides of liberally using CREATE TEMP TABLE ... ON COMMIT DROP |
| Date: | 2018-01-28 14:46:50 |
| Message-ID: | CAHeEsBfRXy15hQVUi_3BP=6mjr46pc+SDwvxpGn5So3_wheZJQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andy Colson | 2018-01-28 15:53:51 | Re: Downsides of liberally using CREATE TEMP TABLE ... ON COMMIT DROP |
| Previous Message | David G. Johnston | 2018-01-28 14:40:01 | Re: Downsides of liberally using CREATE TEMP TABLE ... ON COMMIT DROP |