From: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
---|---|
To: | Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> |
Cc: | 'legrand legrand' <legrand_legrand(at)hotmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: Implementing Incremental View Maintenance |
Date: | 2019-12-23 02:26:09 |
Message-ID: | OSAPR01MB507311815C5BD1A7853AF8C4FE2E0@OSAPR01MB5073.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: legrand legrand <legrand_legrand(at)hotmail(dot)com>
> 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
Does it also include CREATE TEMPORARY TABLE, because there's DROP?
I remember that repeated CREATE and DROP of temporary tables should be avoided in PostgreSQL. Dropped temporary tables leave some unused memory in CacheMemoryContext. If creation and deletion of temporary tables are done per row in a single session, say loading of large amount of data, memory bloat could crash the OS. That actually happened at a user's environment.
Plus, repeated create/drop may cause system catalog bloat as well even when they are performed in different sessions. In a fortunate case, the garbage records gather at the end of the system tables, and autovacuum will free those empty areas by truncating data files. However, if some valid entry persists after the long garbage area, the system tables would remain bloated.
What kind of workload and data are you targeting with IVM?
Regards
Takayuki Tsunakawa
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-12-23 02:35:50 | Re: TCP option assign hook doesn't work well if option not supported |
Previous Message | Michael Paquier | 2019-12-23 01:53:10 | Re: Drongo vs. 9.4 initdb TAP test |