... btw, I noticed a minor misfeature in the current implementation:
regression=# select pg_relation_size('int8_tbl');
pg_relation_size
------------------
8192
(1 row)
regression=# create materialized view mv1 as select * from int8_tbl;
SELECT 5
regression=# select pg_relation_size('mv1');
pg_relation_size
------------------
16384
(1 row)
So when populating a matview, we fail to make any use at all of the
initially-added page. On the other hand,
regression=# vacuum full mv1;
VACUUM
regression=# select pg_relation_size('mv1');
pg_relation_size
------------------
8192
(1 row)
regression=# refresh materialized view mv1;
REFRESH MATERIALIZED VIEW
regression=# select pg_relation_size('mv1');
pg_relation_size
------------------
16384
(1 row)
I haven't looked into why the VACUUM FULL code path is able to make use
of the initially-created page while the CREATE/REFRESH code path can't.
Possibly it's due to some innocent-looking difference in order of
operations. The details aren't really too relevant though. Rather, my
point is that IMO this sort of bug is an inevitable consequence of the
layering violation that's at the heart of the current matview design.
If we stick with this design, I'm afraid we'll be squashing bugs of this
kind till kingdom come, and some of them may be much more painful to fix
than the ones we've found to date. Layering violations tend to beget
more layering violations.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
