Size of regression database

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Size of regression database
Date: 2014-11-13 21:28:12
Message-ID: 19717.1415914092@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2014-11-13 21:33:08 Re: pg_basebackup vs. Windows and tablespaces
Previous Message Robert Haas 2014-11-13 21:24:52 Re: tracking commit timestamps