Re: Rearchitecting for storage - Mailing list pgsql-general

From Jacob Bunk Nielsen
Subject Re: Rearchitecting for storage
Date
Msg-id 877e8dgbdc.fsf@paven.bunk.cc
Whole thread Raw
In response to Re: Rearchitecting for storage  (Matthew Pounsett <matt@conundrum.com>)
List pgsql-general
Matthew Pounsett <matt@conundrum.com> writes:

> [...] Is there any rule of thumb for making sure one has enough space
> available for the upgrade?

No, because it depends greatly on which version you are upgrading from
and which version you are upgrading to etc.

Perhaps you could carve out a slice of data, e.g. 1 GB and load it into
a test database and try to upgrade that. That would probably give you an
idea.

Also, you mentioned that your database contains historical test data¹,
then I would guess that one of the indexes is related to timestamps? But
maybe you could live with a smaller BRIN index for the timestamps:
https://www.postgresql.org/docs/11/brin-intro.html - that could
potentially save some space, and may not have been something on the
radar when the database was first developed.

Best regards,
Jacob

¹) I think I know which kind of data based on your progress reports on
   a DNS related list I'm subscribed to.




pgsql-general by date:

Previous
From: Jacob Bunk Nielsen
Date:
Subject: Re: Rearchitecting for storage
Next
From: Alexandru Lazarev
Date:
Subject: pg_advisory_lock lock FAILURE / What does those numbers mean (process240828 waits for ExclusiveLock on advisory lock [1167570,16820923,3422556162,1];)?