I wrote:
> Kevin Grittner <kgri...@gmail.com> writes:
>> Hm. This seems like a particularly useless size. It would test a
>> possibly useful corner case if it was over 10MB so that it was over
>> vacuum's truncation threshold, but that would obviously be even
>> slower. It doesn't seem justified. How about 500 so it at least
>> goes to a second page which is then truncated to 1 page.
> Yeah, that aspect occurred to me after a bit too. I'll make it so.
Umm... but wait. I stuck some "select pg_relation_size()" calls into
the test sequence to verify what page counts I was getting, and realized
that actually the REFRESH MATERIALIZED VIEW step is leaving the matview
with physical size zero. So there's nothing for VACUUM to do anyway,
and it doesn't matter what size the matview had been before the DELETE
and REFRESH. Maybe we could devise a test that allows VACUUM to be
responsible for actually truncating some pages from a matview, but this
test case ain't it.
I now remember that this test case was intended to exercise the hack
we'd had at the time whereby nonzero physical size signified whether
the matview was populated or not. We got rid of that on the grounds that
it was too fragile, in favor of adding a pg_class.relispopulated column.
No released version of PG has ever had the capacity to have the type of
bug this test is meant to find.
At this point I'm inclined to just delete the whole test. The code
that b69ec7cc9 added is long gone, and I don't think the test deserves
to be memorialized either.
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
