Re: Implementing Incremental View Maintenance - Mailing list pgsql-hackers

From Yugo Nagata
Subject Re: Implementing Incremental View Maintenance
Date
Msg-id 20191224110148.f0bd2967a5cba5b2935405dc@sraoss.co.jp
Whole thread Raw
In response to Re: Implementing Incremental View Maintenance  (legrand legrand <legrand_legrand@hotmail.com>)
Responses Re: Implementing Incremental View Maintenance  (legrand legrand <legrand_legrand@hotmail.com>)
List pgsql-hackers
On Mon, 23 Dec 2019 03:41:18 -0700 (MST)
legrand legrand <legrand_legrand@hotmail.com> wrote:

> Hello,
> regarding my initial post:
> 
> > For each insert into a base table there are 3 statements:
> > - ANALYZE pg_temp_3.pg_temp_81976
> > - WITH updt AS (  UPDATE public.mv1 AS mv SET __ivm_count__ = ...
> > - DROP TABLE pg_temp_3.pg_temp_81976
> 
> For me there where 3 points to discuss:
> - create/drop tables may bloat dictionnary tables 
> - create/drop tables prevents "WITH updt ..." from being shared  (with some
> plan caching)
> - generates many lines in pg_stat_statements
> 
> In fact I like the idea of a table created per session, but I would even
> prefer a common "table" shared between all sessions like GLOBAL TEMPORARY
> TABLE (or something similar) as described here:
>
https://www.postgresql.org/message-id/flat/157703426606.1198.2452090605041230054.pgcf%40coridan.postgresql.org#331e8344bbae904350af161fb43a0aa6

Although I have not looked into this thread, this may be help if this is
implemented. However, it would be still necessary to truncate the table
before the view maintenance because such tables always exist and can be
accessed and modified by any users.


-- 
Yugo Nagata <nagata@sraoss.co.jp>



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: unsupportable composite type partition keys
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: archive status ".ready" files may be created too early