Re: [GENERAL] Vacuum and state_change
От | Adrian Klaver |
---|---|
Тема | Re: [GENERAL] Vacuum and state_change |
Дата | |
Msg-id | a6f26620-957a-a4e5-7fbc-bb427b82a689@aklaver.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] Vacuum and state_change (armand pirvu <armand.pirvu@gmail.com>) |
Ответы |
Re: [GENERAL] Vacuum and state_change
|
Список | pgsql-general |
On 06/09/2017 02:26 PM, armand pirvu wrote: > >> On Jun 9, 2017, at 4:20 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote: >> >> On 06/09/2017 02:01 PM, armand pirvu wrote: >>>> On Jun 9, 2017, at 3:52 PM, Adrian Klaver <adrian.klaver@aklaver.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 moreprecise. We call them temporary since we do drop them after all is said and done. Maybe we should change the way we callthem >> >> 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 havethe 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 thinkingmaybe 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.klaver@aklaver.com
В списке pgsql-general по дате отправления: