PostgreSQL pain points

Posted Apr 4, 2014 10:52 UTC (Fri) by XTF (guest, #83255)
In reply to: PostgreSQL pain points by intgr
Parent article: PostgreSQL pain points

Why would you need to reimplement a FS? How many files does Postgres use anyway?

PostgreSQL pain points

Posted Apr 4, 2014 12:12 UTC (Fri) by intgr (subscriber, #39733) [Link] (2 responses)

Because going with the "raw partition" approach amounts to duplicating lots of effort that already goes into filesystems and VFS: block allocation, free space tracking, fragmentation avoidance, adaptive readahead, durability guarantees in various storage stacks, TRIM on SSDs, page cache. I'm sure I forgot some. And particularly doing all that in a scalable fashion. For instance, PostgreSQL's own shared_buffers has some scalability limits that have not been addressed; the ability to use Linux's page cache greatly improves its performance on large machines.

> How many files does Postgres use anyway?

Postgres uses the file system more extensively (I think) than most databases, here's a short overview of the different kinds of files: http://www.postgresql.org/docs/current/static/storage-fil...

PostgreSQL pain points

Posted Apr 4, 2014 22:22 UTC (Fri) by XTF (guest, #83255) [Link] (1 responses)

A DBMS either already manages most of these things or doesn't need them.

PostgreSQL pain points

Posted Apr 5, 2014 12:26 UTC (Sat) by intgr (subscriber, #39733) [Link]

Thanks, clearly you know better than the people developing given DBMSes.