Re: [HACKERS] [PATCH] A hook for session start

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] [PATCH] A hook for session start
Дата
Msg-id CAFj8pRCT66dxK29H9WfAj3s6g_5kS==Y6d-4actbQp__B9u=kA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH] A hook for session start  (Nico Williams <nico@cryptonector.com>)
Ответы Re: [HACKERS] [PATCH] A hook for session start  (Nico Williams <nico@cryptonector.com>)
Список pgsql-hackers


2017-10-06 6:48 GMT+02:00 Nico Williams <nico@cryptonector.com>:
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?

yes - pg_attribute, pg_class, pg_stats are bloating - and when these tables are bloated, then DDL is slow.



> 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.

me too :) - and lot of customer and users.

There is a workaround - you can use a array instead temp tables in 50%. But it is not a solution in other 50%.

I though about it, but I have other on my top priority. GLOBAL TEMP TABLE is on 90% unlogged table. But few fields should be session based instead shared persistent - statistics, rows in pg_class, filenode.

When we talked about this topic, there are two issues:

a) probably not too hard issue - some internal data can be in session sys cache.

b) the session sys data should be visible on SQL level too (for some tools and consistency) - it is hard task.

Regards

Pavel


Nico
--

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] Proposal: Local indexes for partitioned table
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple