Added to TODO:
o Allow GLOBAL temporary tables to exist as empty by default in
all sessions
http://archives.postgresql.org/pgsql-hackers/2007-07/msg6.php
---
Gregory Stark wrote:
> "Pavel S
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>>> 2007/7/4, Bruce Momjian <[EMAIL PROTECTED]>:
>> The solution is to fix the bloat, not add a work-around.
>
>> The bloat is a direct consequence of performing DDL in the midst of an OLTP
>> transaction.
>
> Hard
Gregory Stark <[EMAIL PROTECTED]> writes:
>> 2007/7/4, Bruce Momjian <[EMAIL PROTECTED]>:
> The solution is to fix the bloat, not add a work-around.
> The bloat is a direct consequence of performing DDL in the midst of an OLTP
> transaction.
Hardly. It's a consequence of our current implementati
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2007/7/4, Bruce Momjian <[EMAIL PROTECTED]>:
>> > 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 th
Pavel Stehule wrote:
> 2007/7/4, Bruce Momjian <[EMAIL PROTECTED]>:
> > > 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
>
2007/7/4, Bruce Momjian <[EMAIL PROTECTED]>:
> 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 create
> 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
On Tue, Jul 03, 2007 at 11:49:05AM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > Tom Lane escribi?:
> > >> I rather doubt that. The most likely implementation would involve
> > >> cloning a "template" entry into pg_class.
> >
> > > How about a
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> 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//pg_temp_
> Global temp table can be created from template only when is used. It's
> has not negative efect on app which doesn't use it. The benefit of
> g.t.t. is simplifycation of stored procedures.
And if it's used in 200 txns/s? Imagine the earlier poster who was looking for
a way to display the count
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> 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
>> PG
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> Global temp table can be created from template only when is used. It's
> has not negative efect on app which doesn't use it. The benefit of
> g.t.t. is simplifycation of stored procedures.
And if it's used in 200 txns/s? Imagine the earlier poster who
2007/7/3, Gregory Stark <[EMAIL PROTECTED]>:
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> while not just a new rekind indicating this is a template and not and
> actual table. and using that template for creating the actual tables?
For precisely the reason stated upthread. That would mean cr
> How about a new relkind which causes the table to be located in
> PGDATA/base//pg_temp_/
> 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_stati
Alvaro Herrera <[EMAIL PROTECTED]> 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//pg_temp_/
> So each backend can have i
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> while not just a new rekind indicating this is a template and not and
> actual table. and using that template for creating the actual tables?
For precisely the reason stated upthread. That would mean creating and
deleting catalog entries for every t
On 7/3/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Tom Lane escribió:
> Jim Nasby <[EMAIL PROTECTED]> writes:
> > I've often thought that having global temp tables would be a really
> > good idea, since it would drastically reduce the need to vacuum
> > catalog tables,
>
> I rather doubt that.
Tom Lane escribió:
> Jim Nasby <[EMAIL PROTECTED]> writes:
> > I've often thought that having global temp tables would be a really
> > good idea, since it would drastically reduce the need to vacuum
> > catalog tables,
>
> I rather doubt that. The most likely implementation would involve
> cl
I
2007/7/2, Tom Lane <[EMAIL PROTECTED]>:
Jim Nasby <[EMAIL PROTECTED]> writes:
> I've often thought that having global temp tables would be a really
> good idea, since it would drastically reduce the need to vacuum
> catalog tables,
I rather doubt that. The most likely implementation would in
Jim Nasby <[EMAIL PROTECTED]> writes:
> I've often thought that having global temp tables would be a really
> good idea, since it would drastically reduce the need to vacuum
> catalog tables,
I rather doubt that. The most likely implementation would involve
cloning a "template" entry into pg_
On Jul 1, 2007, at 4:46 PM, Tom Lane wrote:
I have question. Is correct implementation of global temp in
Oracle or
Firebird, where content of glob.temp table is session visible and
metadata of g.t.t is persistent?
It's correct per spec. Whether it's more useful than what we do is
highly deba
> I have question. Is correct implementation of global temp in Oracle or
> Firebird, where content of glob.temp table is session visible and
> metadata of g.t.t is persistent?
It's correct per spec. Whether it's more useful than what we do is
highly debatable --- it forces all sessions to use th
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> if I understand well, there isn't any difference between local and
> global temp tables in postgresql.
See the archives; some time ago we determined that the correct reading
of the spec is that global/local determines visibility of temp tables
across m
Hello
if I understand well, there isn't any difference between local and
global temp tables in postgresql.
I have question. Is correct implementation of global temp in Oracle or
Firebird, where content of glob.temp table is session visible and
metadata of g.t.t is persistent? Standard is unclean
24 matches
Mail list logo
