luciano/pg_ivm
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Fix README for pg_ivm 1.2

Browse source
This commit is contained in:
Yugo Nagata 2022-07-25 17:31:46 +09:00
parent 6dcfb31848
commit cfe9491e6b
2 changed files with 27 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
README.md
View file

@ -2,7 +2,7 @@
The `pg_ivm` module provides Incremental View Maintenance (IVM) feature for PostgreSQL.
The extension is compatible with PostgreSQL 13 and 14.
The extension is compatible with PostgreSQL 13, 14, and 15.
## Description
@ -182,7 +182,7 @@ Time: 3224.741 ms (00:03.225)
## Supported View Definitions and Restriction
Currently, IMMV's view definition can contain inner joins, DISTINCT clause, and some built-in aggregate functions. Inner joins including self-join are supported, but outer joins are not supported. Supported aggregate functions are count, sum, and avg. Other aggregates including min and max, sub-queries, CTEs, window functions, HAVING, LIMIT/OFFSET, UNION/INTERSECT/EXCEPT, DISTINCT ON, TABLESAMPLE, VALUES, and FOR UPDATE/SHARE can not be used in view definition.
Currently, IMMV's view definition can contain inner joins, DISTINCT clause, some built-in aggregate functions, and simple sub-queries in `FROM` clause. Inner joins including self-join are supported, but outer joins are not supported. Supported aggregate functions are count, sum, avg, min and max. Other aggregates, sub-queries which contain an aggregate or `DISTINCT` clause, sub-queries out of `FROM` clause, CTEs, window functions, `HAVING`, `ORDER BY`, `LIMIT`/`OFFSET`, `UNION`/`INTERSECT`/`EXCEPT`, `DISTINCT ON`, `TABLESAMPLE`, `VALUES`, and `FOR UPDATE`/`SHARE` can not be used in view definition.
The base tables must be simple tables. Views, materialized views, inheritance parent tables, partitioned tables, partitions, and foreign tables can not be used.
@ -194,16 +194,29 @@ Logical replication is not supported, that is, even when a base table at a publi
### Aggregates
Supported aggregate functions are `count`, `sum`, and `avg`. `min` or `max` is not supported. Currently, only built-in aggregate functions are supported and user defined aggregates cannot be used.
Supported aggregate functions are `count`, `sum`, and `avg`, `min`, and `max`. Currently, only built-in aggregate functions are supported and user defined aggregates cannot be used.
When an IMMV including aggregate is created, some extra columns whose name start with `__ivm` are automatically added to the target list. `__ivm_count__` contains the number of tuples aggregated in each group. In addition, more than one extra columns for each column of aggregated value are added in order to maintain the value. For example, columns named like `__ivm_count_avg__` and `__ivm_sum_avg__` are added for maintaining an average value. When a base table is modified, the new aggregated values are incrementally calculated using the old aggregated values and values of related extra columns stored in the IMMV.
Note that using `sum` or `avg` on `real` (`float4`) type or `double precision` (`float8`) type in IMMV is unsafe, because aggregated values in IMMV can become different from results calculated from base tables due to the limited precision of these types. To avoid this problem, use the `numeric` type instead.
Note that for `min` or `max`, the new values could be re-calculated from base tables with regard to the affected groups when a tuple containing the current minimal or maximal values are deleted from a base table. Therefore, it can takes a long time to update an IMMV containing these functions.
Also, note that using `sum` or `avg` on `real` (`float4`) type or `double precision` (`float8`) type in IMMV is unsafe, because aggregated values in IMMV can become different from results calculated from base tables due to the limited precision of these types. To avoid this problem, use the `numeric` type instead.
#### Restrictions on Aggregate
If we have a `GROUP BY` clause, expressions specified in `GROUP BY` must appear in the target list. This is how tuples to be updated in the IMMV are identified. These attributes are used as scan keys for searching tuples in the IMMV, so indexes on them are required for efficient
IVM.
If we have a `GROUP BY` clause, expressions specified in `GROUP BY` must appear in the target list. This is how tuples to be updated in the IMMV are identified. These attributes are used as scan keys for searching tuples in the IMMV, so indexes on them are required for efficient IVM.
Targetlist cannot contain expressions which contain an aggregate in it.
### Subqueries
Simple subqueries in `FROM` clause are supported.
#### Restrictions on Subqueries
Subqueries can be used only in `FROM` clause. Subqueries in target list or `WHERE` clause are not supported.
Subqueries containing an aggregate function or `DISTINCT` are not supported.
### DISTINCT

8
createas.c
View file

@ -1076,6 +1076,14 @@ CreateIndexOnIMMV(Query *query, Relation matviewRel, bool is_create)
List *indexoidlist = RelationGetIndexList(matviewRel);
ListCell *indexoidscan;
/*
* For aggregate withoug GROUP BY, we do not need to create an index
* because the view has only one row.
*/
if (query->hasAggs && query->groupClause == NIL)
return;
snprintf(idxname, sizeof(idxname), "%s_index", RelationGetRelationName(matviewRel));
index = makeNode(IndexStmt);