After discussing performance of PostgreSQL on EXT4, XFS (and also some annoying issues with BTRFS), I've been asked about ReiserFS. I haven't really planned to test that file system, but well - if so many people believe ReiserFS is so fast, maybe it's really faster?

So I gave it a try and the answer is "no"  - it does not beat EXT4 or XFS, at least not in this benchmark on this hardware.

In case you haven't noticed, the schedule for pgconf.eu 2015 was published a few days ago. One of my talks is called PostgreSQL Performance on EXT4, XFS, F2FS, BTRFS and ZFS and aims to compare PostgreSQL performance of modern Linux file systems (and also impact of various tuning options like write barriers, discard etc.). It's not an entirely new talk - it's a reworked (and significantly improved) version of a talk I gave on 5432 conference in May.

One of the rather surprising results was the EXT4 vs XFS comparison - even though XFS is usually presented and perceived as the faster option (and EXT4 as the more "conservative" choice), the results were quite clearly in favor of EXT4. The difference was ~10%, so not a negligible difference. Let me briefly discuss this and also show some of the updated results that I'll present in Vienna. And come to pgconf.eu and see the whole updated talk!

And the final part of my PostgreSQL benchmarking series is here, explaining especially the tremendous GIN improvements in 9.4:

http://blog.pgaddict.com/posts/performance-since-postgresql-7-4-to-9-4-fulltext

Why does PostgreSQL use 8kB pages? Different page size might be more efficient in various cases (e.g. DWH systems often use larger pages). So what factors determine the optimal page size? And how does flash storage (SSDs and such) change the results?

I'd like to briefly look at a potential myth when it comes to databases and I/O schedulers. The purpose of the scheduler is to decide in what order to submit I/O requests (received from the user) to the hardware - it may decide to reorder them, coalesce requests into larger continuous chunks, prioritize requests from some processes etc.

I usually don't write rant-style posts, but today I've decided to make an exception. Over the past few months I've been working on a benchmark comparing how PostgreSQL performs on a variety of Linux filesystems, both traditional ones (EXT3, EXT4, XFS) and new ones (BTRFS, ZFS, F2FS). Sometimes the results came out a bit worse than I hoped for, but most of the time the filesystems behaved quite reasonably and predictably. The one exception is BTRFS ...

Some time ago I explained that there really are two kinds of statistics in PostgreSQL, and I explained what are the common issues with statistics tracking database activity, and how (not to) fix them.

That however does not mean there are no issues with data distribution (planner) statistics, and as that's one of my areas of interest, in this post I'll discuss the common issues with data distribution statistics, usually observed by the user as slow (or even failing) queries. And I'll also mention what are the possible remedies available (if any).

About a week ago, I posted comparison of pgbench results since PostgreSQL 7.4. Now it's time to discuss results of the second benchmark - TPC-DS, which models an analytical workload, i.e. queries processing large amounts of data, with aggregations, large sorts, joins of large tables, TOP-N queries etc.

http://blog.pgaddict.com/posts/performance-since-postgresql-7-4-to-9-4-tpc-ds