PostgreSQL 9.2 Out with Greatly Improved Scalability

The PostgreSQL project announced the release of PostgreSQL 9.2 today. The headliner: "With the addition of linear scalability to 64 cores, index-only scans and reductions in CPU power consumption, PostgreSQL 9.2 has significantly improved scalability and developer flexibility for the most demanding workloads. ... Up to 350,000 read queries per second (more than 4X faster) ... Index-only scans for data warehousing queries (2–20X faster) ... Up to 14,000 data writes per second (5X faster)" Additionally, there's now a JSON type (including the ability to retrieve row results in JSON directly from the database) ala the XML type (although lacking a broad set of utility functions). Minor, but probably a welcome relief to those who need them, 9.2 adds range restricted types. For the gory details, see the what's new page, or the full release notes.

Re:/. Poll

[Eponymous Hero]

E) stop using oracle and start using postgres

Re:LOL

[Tough Love]

Because we love to bash our keyboards into so much plastic scrap whenever we come across one of its many standards-defiant idiosyncracies?

You mean, idiosyncracies different from Oracle's idiosyncracies, Microsoft's idiosyncracies and IBM's idiosyncracies?

By the way, care to be specific? Oh yeah, posting anon. Right.

MariaDB and Percona

[kbahey]

Oracle is not that big a of concern.

There is MariaDB [mariadb.org] which is data-compatible with MySQL, and has some nice additions (like microsecond performance data), and there is also Percona Server [percona.com].

If Oracle messes up, like they did with OpenOffice, there will be another version that they cannot touch, like LibreOffice.

Re:meh

[Anonymous Coward]

Wake me when MemSQL supports data-warehousing.

Re:That's great and all, but . . .

[schmiddy]

There is a serious problem with this patch on BSD kernels. All of the BSD sysv implementations have a shm_use_phys optimization which forces the kernel to wire up memory pages used to back SysV segments. This increases performance by not requiring the allocation of pv entries for these pages and also reduces memory pressure. Most serious users of PostgreSQL on BSD platforms use this well-documented optimization. After switching to 9.3, large and well optimized Pg installations that previously ran well in memory will be forced into swap because of the pv entry overhead.

I don't see your comment on the blog (maybe it has to be approved?), but the same issue was raised here [nabble.com] during review of the patch. The concern was mostly blown off (most PG developers use Linux instead of BSD, that might well be part of it), but if you had some numbers to back up your post, the -hackers list would definitely be interested. Ideally, you could give numbers and a repeatable benchmark showing a deterioration of 9.3-post-patch vs. 9.3-pre-patch on a BSD. If that's too much work, just the numbers from a dumb C program reading/writing shared memory with mmap() vs. SysV would be a good discussion basis.