Hi, On 2021-05-21 11:01:03 -0400, Tom Lane wrote: > It was a good thing I went through this code, too, because I noticed > one serious bug (attcompression not checked in equalTupleDescs) and > another thing that looks like a bug: there are two places that set > up attcompression depending on > > if (rel->rd_rel->relkind == RELKIND_RELATION || > rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE) > > This seems fairly nuts; in particular, why are matviews excluded?
Yea, that doesn't seem right. I was confused why this appears to work at all right now. It only does because REFRESH always inserts into a staging table first - which is created as a normal table. For non-concurrent refresh that relation's relfilenode is swapped with the MV's. For concurrent refresh we actually do insert into the MV - but we never need to compress a datum at that point, because it'll already have been compressed during the insert into the temp table. I think there might something slightly off with concurrent refresh - the TEMPORARY diff table that is created doesn't use the matview's compression settings. Which means all tuples need to be recompressed unnecessarily, if default_toast_compression differs from a column in the materialized view. SET default_toast_compression = 'lz4'; DROP MATERIALIZED VIEW IF EXISTS wide_mv; CREATE MATERIALIZED VIEW wide_mv AS SELECT 1::int4 AS key, random() || string_agg(i::text, '') data FROM generate_series(1, 10000) g(i);CREATE UNIQUE INDEX ON wide_mv(key); ALTER MATERIALIZED VIEW wide_mv ALTER COLUMN data SET COMPRESSION pglz; REFRESH MATERIALIZED VIEW CONCURRENTLY wide_mv; With the SET COMPRESSION pglz I see the following compression calls: 1) pglz in refresh_matview_datafill 2) lz4 during temp table CREATE TEMP TABLE AS 3) pglz during the INSERT into the matview Without I only see 1) and 2). Greetings, Andres Freund