Hi, src_backend_commands_matview.c 547: /* 548: * refresh_by_match_merge 549: * 550: * Refresh a materialized view with transactional semantics, while allowing 551: * concurrent reads. 552: * 553: * This is called after a new version of the data has been created in a 554: * temporary table. It performs a full outer join against the old version of 555: * the data, producing "diff" results. This join cannot work if there are any 556: * duplicated rows in either the old or new versions, in the sense that every 557: * column would compare as equal between the two rows. It does work correctly 558: * in the face of rows which have at least one NULL value, with all non-NULL 559: * columns equal. The behavior of NULLs on equality tests and on UNIQUE 560: * indexes turns out to be quite convenient here; the tests we need to make 561: * are consistent with default behavior. If there is at least one UNIQUE 562: * index on the materialized view, we have exactly the guarantee we need. 563: * 564: * The temporary table used to hold the diff results contains just the TID of 565: * the old record (if matched) and the ROW from the new table as a single 566: * column of complex record type (if matched). 567: * 568: * Once we have the diff table, we perform set-based DELETE and INSERT 569: * operations against the materialized view, and discard both temporary 570: * tables. 571: * 572: * Everything from the generation of the new data to applying the differences 573: * takes place under cover of an ExclusiveLock, since it seems as though we 574: * would want to prohibit not only concurrent REFRESH operations, but also 575: * incremental maintenance. It also doesn't seem reasonable or safe to allow 576: * SELECT FOR UPDATE or SELECT FOR SHARE on rows being updated or deleted by 577: * this command. 578: */ 579:
> Once we have the diff table, we perform set-based DELETE and INSERT > operations against the materialized view, and discard both temporary > tables. > Here the temporary tables are "discard" meaning the temporary tables are deleted and the temporary tables' spaces are reclaimed immediately? Or the temporary tables are deleted and the spaces will be reclaimed by another mechanism? simplify:does refreshing materialized view make the database bloat.
