does refreshing materialized view make the database bloat?

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.