Re: Rearchitecting for storage

From: Jacob Bunk Nielsen <jacob(at)bunk(dot)cc>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Rearchitecting for storage
Date: 2019-07-19 17:52:47
Message-ID: 877e8dgbdc.fsf@paven.bunk.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Matthew Pounsett <matt(at)conundrum(dot)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.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Alexandru Lazarev 2019-07-19 18:15:03 pg_advisory_lock lock FAILURE / What does those numbers mean (process 240828 waits for ExclusiveLock on advisory lock [1167570,16820923,3422556162,1];)?
Previous Message Jacob Bunk Nielsen 2019-07-19 17:39:16 Re: Rearchitecting for storage