Profile cover photo
Profile photo
Tomáš Vondra
110 followers
110 followers
About
Tomáš's posts

Post has attachment
Každoroční konference Prague PostgreSQL Developer Day. Středeční školení jsou již plně obsazena, ale na konferenci ve čtvrtek 16.2. nám tam ještě pár míst zbývá. Program konference, anotace přednášek i registraci najdete na našich stránkách http://p2d2.cz.

Post has shared content
Máte přednášku na zajímavé téma související s PostgreSQL? Přihlaste ji na konferenci P2D2 (Prague PostgreSQL Developer Day) která se koná již 17-18. 2. 2016.
Ještě jste nepřihlásili svou přednášku (nebo školení) na Prague PostgreSQL Developer Days 2016? Není nač čekat, přihlášky přijímáme pouze do 11.1.2016, tj. zbývá méně než 7 dní!

http://p2d2.cz/rocnik-2016/call-for-papers

Post has attachment
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?

Post has shared content
Listopadový PostgreSQL meetup se bude konat ve čtvrtek 26.11. od 18:00 na ČVUT FIT v Dejvicích. Na programu jsou dvě přednášky:

* SQL Tabs - alternativní PostgreSQL klient (Aliaksandr Aliashkevich)
* Optimalizace PL/pgSQL (Pavel Stěhule)

Jak se na meetup dostat - ideálně přes vchod Fakulty stavební, Thákurova 7. Na vrátnici stačí říct že jdete na FIT do 9. patra (případně se ohánějte Michalem Valentou který tam učí), doprava k výtahu a do 9. patra.

Po meetupu se ideálně vydáme někam na pivko - pokud máte zájem o účast, ozvěte se v komentáři ať můžeme zarezervovat místa a nedopadneme jako minule.

Post has attachment
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.

Post has attachment
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.

Post has attachment
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 ...

Post has attachment
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!

Post has attachment
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).

Post has attachment
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
Wait while more posts are being loaded