On Fri, Oct 06, 2017 at 04:52:09AM +0200, Pavel Stehule wrote:
> 2017-10-05 22:31 GMT+02:00 Nico Williams <nico@cryptonector.com>:
> > On Tue, Aug 01, 2017 at 03:36:23PM -0400, Peter Eisentraut wrote:
> > > On 7/21/17 13:14, Jim Mlodgenski wrote:
> > > > When I first saw this thread, my initial thought of a use case is to
> > > > prepare some key application queries so they are there and ready to go.
> > > > That would need to be before the ExecutorStart_hook or
> > > > ProcessUtility_hook if an app would just want to execute the prepared
> > > > statement.
> > >
> > > Isn't that what the preprepare extension does already?
> >
> > more generic facility -> more useful
> >
> > My use case is to pre-create TEMP schema elements that VIEWs, FUNCTIONs,
> > and TRIGGERs, might need.
>
> It is better to work on GLOBAL TEMP tables.
I don't disagree.
In fact, I was scoping out what it might take to do that just yesterday.
I've too thoughts on that: either a new relpersistence kind that is very
similar to persistent, but which always uses temp heaps, or a modifier
for the persistent kind that says to use temp heaps. Either way it
looks like it should be fairly straightforward (but then, i've only
ever written one thing for PG, earlier this week, the ALWAYS DEFERRED
thing).
> Current TEMP tables, if you do it for any session has pretty significant
> overhead - with possible risk of performance lost (system catalog bloat).
Because of the DDLs for them?
> So often creating local temp tables is antipattern (in Postgres)
> unfortunately.
I do it plenty, but sometimes I use an UNLOGGED table with a txid column
in the PK set to txid_current(), then I clean up where I can. It'd be
nice to have COMMIT triggers for cleaning up such rows, among other
things. I've implemented that using DDL event triggers, but to perform
well it needs to be a native feature.
> I am not sure, if we should to support this case more :( Probably is
> better, so it is hard to use local TEMP tables.
No, I want GLOBAL TEMP tables.
Nico
--
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers