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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
