Size of regression database - Mailing list pgsql-hackers

From Tom Lane
Subject Size of regression database
Date
Msg-id 19717.1415914092@sss.pgh.pa.us
Whole thread Raw
Responses Re: Size of regression database  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
I was testing backwards compatibility of pg_dumpall just now, and was
somewhat astonished to notice the size of the output for the regression
database compared to what it was not too long ago:

-rw-rw-r--. 1 tgl tgl  4509135 Nov 13 16:19 dumpall.83
-rw-rw-r--. 1 tgl tgl  4514441 Nov 13 16:24 dumpall.84
-rw-rw-r--. 1 tgl tgl  4666917 Nov 13 16:15 dumpall.90
-rw-rw-r--. 1 tgl tgl  4681235 Nov 13 16:15 dumpall.91
-rw-rw-r--. 1 tgl tgl  5333587 Nov 13 16:15 dumpall.92
-rw-rw-r--. 1 tgl tgl  5409083 Nov 13 16:15 dumpall.93
-rw-rw-r--. 1 tgl tgl  5493686 Nov 13 16:15 dumpall.94
-rw-rw-r--. 1 tgl tgl 27151777 Nov 13 16:21 dumpall.head

A quick eyeball check says that that quintupling of the database size
is all in BRIN index tests.  Could we dial that back to something a
bit saner please?  It's unlikely that the last 20 meg are testing anything
that the first half meg didn't, and there are lots of use cases wherein
there is good reason to care about the size of the regression database.
Buildfarm, for instance.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: tracking commit timestamps
Next
From: Peter Eisentraut
Date:
Subject: Re: pg_basebackup vs. Windows and tablespaces