5 ms·
We use it on medium size tables (around ~100M rows and ~100GB each). No problems. The perf boost we get from clustering rows in the right spot on the disk is hu
by cldellow 11y ago
We use it on medium size tables (around ~100M rows and ~100GB each). No problems. The perf boost we get from clustering rows in the right spot on the disk is huge.
- e12e 11y agoOut of curiosity, as you apparently have some real data and real use-cases - have you benchmarked SSD vs disk for your use-case? In particular, do you still see a (comparable, or not) speed-up from better clustering of rows on SSD? (I would guess not, unless you have a lot of fragmentation at less than SSD write-size (typically 4k?) - and AFAIK postgres should already be trying to fix that for you, by how it lays out data on disk. But SSD do have somewhat better sequential read than random-read, even if not as dramatic as spinning disks).
- cldellow 11y agoThere's still a speedup, but it's dwarfed by the magnetic->SSD boost. We do have fragmentation within a block. Our records on the heap are about 150 bytes, so maybe 30 rows per 4K page. In the pathological case where there is 1 row per page due to fragmentation, queries have to fetch 30x the number of blocks, which is a killer on a spinny disk.
- codinghorror 11y agoPeople still use spinning rust for databases?
- dikaiosune 11y agoI have to deal with a couple of plattered databases. It's not optimal, but there's usually some cost constraint, or there are only 100 users on it a week. Or both, in which case it's no big deal and it's very very cheap.