On Mon, 2013-03-04 at 22:13 +0200, Heikki Linnakangas 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.
Is there any reason why we can't have both postgres and filesystem checksums? The same user might not want both (or might, if neither are entirely trustworthy yet), but I think it's too early to declare one as the "right" solution and the other not. Even with btrfs stable, I pointed out a number of reasons users might not want it, and reasons that the project should not depend on it. Numbers are always nice, but it takes a lot of effort to come up with them. What kind of numbers are you looking for, and how *specifically* will those numbers affect the decision? If btrfs with checksums is 10% slower than ext4 with postgres checksums, does that mean we should commit the postgres checksums? On the other side of the coin, if btrfs with checksums is exactly the same speed as ext4 with no postgres checksums (i.e. checksums are free if we use btrfs), does that mean postgres checksums should be rejected? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers