News for hackers. Stuff that matters.
Re:PostgreSQL Indexes: First principles by tominous on Friday February 26, 2016 @09:25PM (#11185769)
It's also tricky with a COW filesystem like ZFS in which the order of data on-disk may not match the logical order of the file. So your database may decide to dispatch a bunch of sequential 1MB reads to the filesystem, only for the filesystem to translate those large sequential reads into many small random 8kB reads. It depends on how fragmented the file is, so you can start off with great performance which degrades significantly over time.

Luckily SSDs have a much lower penalty for random reads compared to spinning disks, so in future this will be less of an issue.

In the meantime all you can do is use a different filesystem, hide the problem with cache, or manually defragment your data files from time to time.

Re:PostgreSQL Indexes: First principles by pkaye on Friday February 26, 2016 @11:25PM (#11186054)
Actually SSD themselves implement COW filesystem since NAND cannot be written without erase step.
Re:PostgreSQL Indexes: First principles by tominous on Saturday February 27, 2016 @01:44AM (#11186321)
That's true but not particularly relevant to database performance. As I mentioned, random reads on an SSD do not suffer from a head seek penalty so it doesn't matter how the blocks are allocated. On the other hand with spinning disk there is a huge difference in throughput for large sequential vs small random reads.
Re:PostgreSQL Indexes: First principles by pmalynin on Saturday February 27, 2016 @01:38AM (#11186315)
What about TRIM?
Re:PostgreSQL Indexes: First principles by pkaye on Saturday February 27, 2016 @02:23PM (#11188067)
TRIM is like the free() equivalent to malloc(). It releases a NAND page back to free state for other uses. It dones't require any NAND access or writes per-se but if persistent TRIM is needed (vs best effort,) it gets much more complicated.