Search code examples
postgresqllayoutsolid-state-drive

Postgres: Do you still separate data and indexes with SSDs


Are folks still keeping data and indexes separate for performance or do the current SSDs make this a quaint practice from the past?

Ive been presented with a new stand alone system with (12 4 TB ssd ) in 6 RAID0 mirrors with RAID1 stripe laid on top of them and presented as a single mount point (/pgdata/vd0).

Asking if other DBAs would ask to have this rebuilt and have heated interactions with the hardware guys or just run with it and put a datawarehouse on this?

Just asking at a high level


Solution

  • The answer is always "it depends". If the indexes typically fit in RAM, it won't matter. If the data you're pulling out includes large result sets from the disks, it probably won't make much of a difference since the random access on the HDDs will dominate the total interaction.

    SSDs make a huge difference with OLTP workloads that make a lot of random access calls, but not just limited to the indexes. SSDs just make everything much faster.

    This practice is also often superseded by options like ZFS's Adaptive Replacement Cache which intelligently send reads/writes of the most used sectors to the SSD for speed in a similar fashion to SSHDs, but filesystem-based.

    All that said, every database is different: in structure, in volume, and in usage patterns. The best way to tune both the hardware and the software is to test your specific use cases and profile the results. There are no silver bullets, and this includes the "index on an SSD" option.