From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | armand pirvu <armand(dot)pirvu(at)gmail(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Vacuum and state_change |
Date: | 2017-06-09 22:42:57 |
Message-ID: | a6f26620-957a-a4e5-7fbc-bb427b82a689@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 06/09/2017 02:26 PM, armand pirvu wrote:
>
>> On Jun 9, 2017, at 4:20 PM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> wrote:
>>
>> On 06/09/2017 02:01 PM, armand pirvu wrote:
>>>> On Jun 9, 2017, at 3:52 PM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> wrote:
>>>>
>>>> On 06/09/2017 01:31 PM, armand pirvu wrote:
>>>>
>>>>>>
>>
>>
>>> By temporary tables I mean just regular table not tables created by "create temporary table" . I should have been more precise. We call them temporary since we do drop them after all is said and done. Maybe we should change the way we call them
>>
>> You will want to look at this before making that decision:
>>
>> https://www.postgresql.org/docs/9.6/static/sql-createtable.html
>>
>> Temporary Tables
>>
>>
>> Basically, temporary tables are session specific.
>>
>
> I noticed that, but since we use multiple schemas can not have a session temp table in non temp schema
A true temporary table is going to be in its own temporary schema:
https://www.postgresql.org/docs/9.6/static/runtime-config-client.html#GUC-SEARCH-PATH
"Likewise, the current session's temporary-table schema, pg_temp_nnn, is
always searched if it exists. It can be explicitly listed in the path by
using the alias pg_temp. If it is not listed in the path then it is
searched first (even before pg_catalog). However, the temporary schema
is only searched for relation (table, view, sequence, etc) and data type
names. It is never searched for function or operator names."
>
> We have those in place for a specific reason in case we mess some processing in between and we want to be able to have the data which we started with.
>
>
>
>>
>
> As of now I don’t think we have a draw back per se. We are poised to go live on Postgres soon though so I was thinking maybe have this upgrade done before going live ? Just a thought
>
Yeah well if you are in pre-production why not, if no other reason then
you get another year of community support on the back end.
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-06-09 22:46:08 | Re: Performance issue with Pointcloud extension |
Previous Message | Neil Anderson | 2017-06-09 22:03:26 | Re: pg_catalog tables don't have constraints? |