| From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
|---|---|
| To: | "Bruce Momjian" <bruce(at)momjian(dot)us> |
| Cc: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Alvaro Herrera" <alvherre(at)commandprompt(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-04 07:22:11 |
| Message-ID: | 162867790707040022g3d21beddsb6949e5f225be650@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
2007/7/4, Bruce Momjian <bruce(at)momjian(dot)us>:
> > The use case is any system that uses temp tables in an OLTP setting,
> > which certainly isn't uncommon. The problem is that today (and as well
> > with a global temp table that is still writing to the catalogs) is that
> > every OLTP operation that creates or drops a temp table is doing DDL.
> > At best, that leads to a lot of catalog bloat. Right now, it appears to
> > also expose some race conditions (we've got a customer that's been bit
> > by this and we've been able to reproduce some odd behavior in the lab).
>
> The solution is to fix the bloat, not add a work-around.
>
Catalog bloat is one unwanted effect. Second is different behave of
temp tables than other mayor rdbms, and uncomfortable work with temp
tables in stored procedures. Third argument for implementation of
global temp tables is full support of ANSI SQL,
Regards
Pavel Stehule
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zdenek Kotala | 2007-07-04 07:39:25 | Re: Proposal: In-Place upgrade concept |
| Previous Message | Bruce Momjian | 2007-07-04 03:20:27 | Re: what is difference between LOCAL and GLOBAL TEMP TABLES in PostgreSQL |