On Wed, May 3, 2017 at 4:37 PM, Tom Lane wrote:
> At this point I'm inclined to just delete the whole test.
ok
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://w
I wrote:
> Kevin Grittner 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
Kevin Grittner writes:
> On Wed, May 3, 2017 at 12:08 PM, Tom Lane 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.
On Wed, May 3, 2017 at 12:08 PM, Tom Lane 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 use
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 ma
