A colleague of mine (thanks Jimbo!) pointed me towards a benchmark comparison of Postgres 8.3.8 on RHEL 5.4 versus SQL Server 2008 R2 on Windows Server 2008 R2, performed and written up by Red Hat. I hadn't seen it before, so figured that maybe others hadn't either:
http://www.redhat.com/pdf/rhel/bmsql-postgres-sqlsrvr-v1.0-1.pdf
Can't wait for the result? The elephant wins :-)
I don't understand the wacky disk configuration: disks all sliced up, using RAID0.
ReplyDeleteDavid,
ReplyDeleteNot to say there is anything wrong with these benchmarks aside from the obvious. Its like me trusting Microsoft's claim that SQL Server scales better than Oracle or Oracle claiming their database is better than SQL Server. it would be really nice to see these benchmarks done by an impartial party who is very knowledgeable of both systems.
It would be really nice to see the PostgreSQL benchmarks on windows against SQL Server windows. Just because I know a lot of people who will never change their Windows 2008 R2 and will stick with SQL Server 2008 R2 just because they perceive the speed to be much better on Windows than what they will get with PostgreSQL.
I personally haven't found that to be the case. PostgreSQL speed seems pretty good on Windows and unpar if not better than SQL Server 2008 at least for my workloads, but I haven't done any benchmarking.
Thanks,
Regina
Baron, Regina
ReplyDeleteI'm just reporting existence of the paper in this case - I had no involvement with the work, and as far as I'm aware, EnterpriseDB just helped out with some PostgreSQL tuning advice.
The reader will need to make up his or her mind about whether to trust what they read based on the the evidence and methodology presented - as should always be the case :-)
Dave, absolutely. I was kind of wondering if anyone else knew why they chose that disk configuration -- or knew of a DBA who would choose such a disk configuration. I suppose it's pointless to ask such questions about a benchmark, though.
ReplyDeleteIsn't it kind of cheating to turn autovac off? Seems like an actual production environment would have this on. Manually tuning a vacuum schedule for a high OLTP load sounds like a PITA.
ReplyDeleteI can comment on the RAID0 issue since I was the one that made that recommendation. It was strictly used to get the most performance out of the hardware that was on-hand. It was not meant as a recommendation for production use. Since both Postgres and SQL Server both used the same disks and RAID setup, it was a fair comparison between the 2. As far as Autovac being off, I think I remember that the numbers were almost the same wether it was on or off and ending up being off was just an artifact of tweaking configs to get results, but I'm not entirely sure.
ReplyDeleteDoes anyone know how RedHat got away with publishing these benchmarks? If I remember correctly Microsoft prohibits publishing benchmarks of SQL-Server without its approval.
ReplyDeleteI consider both turning autovacuum off and setting checkpoint_timeout so high to be mild forms of cheating. I'm sure there are similar knobs you can disable in SQL Server to bypass normal operations just to tweak benchmark performance that weren't used here.
ReplyDeleteJust two comments:
ReplyDelete1) If a tuning of Postgres has been made, why the same kind of tuning has not been done for the sql server? If this tuning wasn't possible, why not using the default configuration for Postgres (excepting max_connections).
2) Making running the two servers on the same OS looks more straightforward...