| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Jim Nasby <decibel(at)decibel(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: what is difference between LOCAL and GLOBAL TEMP TABLES in PostgreSQL |
| Date: | 2007-07-03 15:49:05 |
| Message-ID: | 200707031549.l63Fn5W25742@momjian.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Tom Lane escribi:
> >> I rather doubt that. The most likely implementation would involve
> >> cloning a "template" entry into pg_class.
>
> > How about a new relkind which causes the table to be located in
> > PGDATA/base/<dboid>/pg_temp_<backendid>/<relfilenode>
> > So each backend can have its own copy of the table with the same
> > relfilenode; there's no need for extra catalog entries.
>
> Uh-huh. And what do you do with relpages, reltuples, relfrozenxid, and
> pg_statistic entries? What if one backend wants to TRUNCATE or CLUSTER
> its copy (requiring a new relfilenode)? Where does ALTER TABLE fit into
> this?
And what is the use-case for this functionality? What does it give us
that we don't already have?
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Naz Gassiep | 2007-07-03 16:00:08 | Re: todo: Hash index creation |
| Previous Message | Tom Lane | 2007-07-03 15:36:03 | Re: Proposal: In-Place upgrade concept |