Thread: [HACKERS] How huge does mvtest_huge need to be?
Continuing to investigate possible speedups of the regression tests,
I noticed that some of the slower individual statements are those
dealing with mvtest_huge and mvtest_hugeview in matview.sql.
Cutting the size of mvtest_huge from 100K rows to 10K rows is enough
to halve the overall runtime of matview.sql, at least on the relatively
slow buildfarm animal I was checking this on.
I was going to propose doing that, but then looking at commit b69ec7cc9
which introduced these tables, I began to wonder why they're large at all.
Even a one-row matview would have been enough to test for the bug that
that commit fixed.
So ... is there a good reason to be using a large table here, and
if so what is it, and how big does the table really need to be
to provide useful test coverage?
regards, tom lane
On Wed, May 3, 2017 at 12:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > So ... is there a good reason to be using a large table here, and > if so what is it, and how big does the table really need to be > to provide useful test coverage? 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. The "huge" in the object names then seems odd, of course. -- Kevin Grittner VMware vCenter Server https://www.vmware.com/
Kevin Grittner <kgrittn@gmail.com> writes:
> On Wed, May 3, 2017 at 12:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So ... is there a good reason to be using a large table here, and
>> if so what is it, and how big does the table really need to be
>> to provide useful test coverage?
> 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.
> The "huge" in the object names then seems odd, of course.
Right ... will pick some other name.
regards, tom lane
I wrote:
> Kevin Grittner <kgrittn@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
On Wed, May 3, 2017 at 4:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > At this point I'm inclined to just delete the whole test. ok -- Kevin Grittner VMware vCenter Server https://www.vmware.com/