Thx for testing !

- Try creating an index on the referenced table and re-run the bulk modify/bulk delete tests in PostgreSQL. Should be *much* faster.

- Also, you say you wanted to test “crash proof databases”. Run the tests again, and do the power plug test when the disk is busy. Does MySQL handle recovery as well as PostgreSQL does?

You’ve adjusted commit_delay = 1000, which is a bad idea too. Leave that one at the default. I doubt it will impact any of your tests, but it’s a badly implemented feature. It doesn’t do what you’d expect from the documentation, and it’s due to be retired soon. The effective impact of increasing that parameter right now is that you could be adding needless waits for a commit in some circumstances.

The rest of your PostgreSQL configuration is decent, and I’d think a fair representative of what a basic (non-database expert) tuned database would look like given your hardware. Good job. There’s a guide to this area at http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server that covers most of what people know to get started here you might pick up some hints from. You might get a little boost by changing wal_buffers=16MB on some of the write-heavy tests here.

As for the slow deletes, that could just be PostgreSQL having more overhead when deleting a record due to the MVCC scheme it uses to handle transaction visibility. That same overhead is what dramatically reduces locking and therefore improves scalability in more common read tasks, so in some respects it’s probably want you want. There are also some easy mistakes to make in how you setup foreign keys in PostgreSQL, and I’m not sure if osdb has been audited to look for those recently. I don’t see one thing I’d expect on a quick glance at its source code, so it’s possible you’re seeing an unfair comparison difference in the benchmark code itself. Will have to take a look at exactly what it’s doing here to confirm whether that’s really the case or not.

Also, it appears that the database only contained 1 GB of data, and the available RAM exceeded that. In such situations you generally get better plans in PostgreSQL by configuring random_page_cost and seq_page_cost both to 0.01. The given configuration would be more appropriate for a PostgreSQL database with hundreds or thousands of GB; and even there I usually have enough of the active portion of the database cached to drop random_page_cost to 2.

Running database benchmarks from a “generic” partition where all the rest of the system data is, and especially running benchmarks on different databases installed on the same partition / file system one after the other can unbelievably increase file system fragmentation.

Regards

MySQL automatically creates indexes on foreign keys which speeds up modifies/deletes on referenced fields at the expense of modify/insert performance on the referencing field. Postgresql lets you decide