Alan, thanks for your reply.
So, we currently have this situation:
/dev/sda1 2.7T 2.4T 298G 90% /data/vol1
/dev/sdb2 2.7T 2.4T 296G 89% /data/vol2
/dev/mapper/vg00-data
16T 16T 373G 98% /data/vol3
postgres=# SELECT * FROM pg_tablespace;
spcname | spcowner | spclocation | spcacl
------------+----------+-------------+-----------------------------------
pg_default | 10 | |
pg_global | 10 | |
vol1 | 10 | /data/vol1 | {postgres=C/postgres,=C/postgres}
vol2 | 10 | /data/vol2 | {postgres=C/postgres,=C/postgres}
vol3 | 10 | /data/vol3 | {postgres=C/postgres,=C/postgres}
(5 rows)
And we added new volume yday:
/dev/mapper/vg00-vol4
4.0T 195M 3.8T 1% /data/vol4
So, if I understood you correctly, it is better to extend vol3 instead of
creating new tablespace on vol4 (if possible).
If not, then what is my best bet?
Thanks,
Julie
________________________________
From: Alan Hodgson <ahodg...@lists.simkin.ca>
Sent: Thursday, May 9, 2019 9:15 AM
To: Julie Nishimura; pgsql-general
Subject: Re: running out of disk space
On Thu, 2019-05-09 at 15:46 +0000, Julie Nishimura wrote:
hello,
We are running out of disk space, and we introduced new volume to it. I am
about to create new tablespace X and alter user databases to set to this new
tablespace X. So, all new tables will be created in X, but what about existing
tables on previous volume? Its data will be split between 2 tbspaces?
Please clarify. Thank you!
Tables and indexes can only be on one tablespace. You'll need to individually
move them with alter table and alter index. They will be locked while being
moved. You should experiment with this on a test server to learn how it works.
However, unless your new volume has different I/O characteristics than the
existing volume you really shouldn't use tablespaces. You should use your OS
volume manager and filesystem tools to extend the data volume and filesystem
into the new space. This will be much easier to manage. I'm sure your system
administrator can assist you with this.
