Unless this is about reads exclusively I would start with putting wal on ssd.
What you might also do, is create separate filesystems (lvm). You can then keep track of io with iostat per filesystem and see what would benefit most. And see storage size usage also.
And you could use lvm to move filesystems to and from ssd hot. So just downtime once.
Please share your end findings in this thread too.
Op wo 19 feb. 2020 om 04:42 schreef Nicolas PARIS <nicolas.paris@xxxxxxxxxx>
Hi
I have both hdd and ssd disk on the postgres server. The cluster is
right now created on the hdd only. I am considering using a tablespace
to put some highly used postgres object on the ssd disk. Of course the
ssd is small compared to the hdd, and I need to choose carefully what
objects are stored on that side.
I am wondering what kind of object (indexes, data) would benefit from
ssd. The database primary/foreign keys are highly used and there is
almost no sequencial scan. However the server has a large amount of ram
memory and I suspect all of those indexes are already cached in ram.
I have read that tablespaces introduce overhead of maintenance and
introduce complication for replication. But on the other hand I have
this ssd disk ready for something.
Any recommandation ?
--
nicolas paris
Sebastiaan Alexander Mannem Product Manager | |||||
| Anthony Fokkerweg 1 1059 CM Amsterdam, The Netherlands | |||||
| www.edbpostgres.com | |||||
