Re: idea: global temp tables - Mailing list pgsql-hackers

From Greg Stark
Subject Re: idea: global temp tables
Date
Msg-id 4136ffa0904290812rd018bffl16a8336a88c14b1e@mail.gmail.com
Whole thread Raw
In response to Re: idea: global temp tables  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: idea: global temp tables  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
On Tue, Apr 28, 2009 at 6:18 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> I was thinking in terms of throwing a warning in 8.4 and
>> implementing new behavior in 8.5.
>
> If we're on that time frame with it, I guess it's not too early to
> suggest what we would implement in 8.5.
>
> I would suggest that it is clear that what Pavel is requesting is
> fully compliant with the spec's definition of global temporary tables.

I think there are implicit assumptions that the spec is making about
the performance implications of using these temporary tables. It's
offering a tool that can reasonably be used in place of views and CTEs
in otherwise pure DML.

I didn't follow precisely what Pavel was describing but IMHO anything
which does any DDL, even implicitly, would be make the feature
impractical in many cases where it really ought to work. Anything
which causes pg_class to bloat or require special vacuum strategies is
just not going to scale.

The whole point of having the schema declared in advance and then
having each procedure execution have access to a private (or
non-private) data store following that predefined schema is to avoid
having to execute any catalog changes with all the locking and catalog
i/o that DDL requires.

--
greg


pgsql-hackers by date:

Previous
From: Andy Lester
Date:
Subject: Throw some low-level C scutwork at me
Next
From: "Kevin Grittner"
Date:
Subject: Re: idea: global temp tables