On Mon, Mar 4, 2013 at 3:13 PM, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > On 04.03.2013 20:58, Greg Smith wrote: >> >> There >> is no such thing as a stable release of btrfs, and no timetable for when >> there will be one. I could do some benchmarks of that but I didn't think >> they were very relevant. Who cares how fast something might run when it >> may not work correctly? btrfs might as well be /dev/null to me right >> now--sure it's fast, but maybe the data won't be there at all. > > This PostgreSQL patch hasn't seen any production use, either. In fact, I'd > consider btrfs to be more mature than this patch. Unless you think that > there will be some major changes to the worse in performance in btrfs, it's > perfectly valid and useful to compare the two. > > A comparison with ZFS would be nice too. That's mature, and has checksums.
We've had a few EnterpriseDB customers who have had fantastically painful experiences with PostgreSQL + ZFS. Supposedly, aligning the ZFS block size to the PostgreSQL block size is supposed to make these problems go away, but in my experience it does not have that effect. So I think telling people who want checksums "go use ZFS" is a lot like telling them "oh, I see you have a hangnail, we recommend that you solve that by cutting your arm off with a rusty saw". There may be good reasons to reject this patch. Or there may not. But I completely disagree with the idea that asking them to solve the problem at the filesystem level is sensible. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers