Hi Fabien,
Hello Tomas.
On 2016-01-11 14:45:16 +0100, Andres Freund wrote:I measured it in a different number of cases, both on SSDs and spinning rust. I just reproduced it with: postgres-ckpt14 \ -D /srv/temp/pgdev-dev-800/ \ -c maintenance_work_mem=2GB \ -c fsync=on \ -c synchronous_commit=off \ -c shared_buffers=2GB \ -c wal_level=hot_standby \ -c max_wal_senders=10 \ -c max_wal_size=100GB \ -c checkpoint_timeout=30sWhat kernel, filesystem and filesystem option did you measure with?
Andres did these measures, not me, so I do not know.
I was/am using ext4, and it turns out that, when abling flushing, the results are hugely dependant on barriers=on/off, with the latter making flushing rather advantageous. Additionally data=ordered/writeback makes measureable difference too.
These are very interesting tests, I'm looking forward to have a look at the results.
The fact that these options change performance is expected. Personnaly the test I submitted on the thread used ext4 with default mount options plus "relatime".
If I had a choice, I would tend to take the safest options, because the point of a database is to keep data safe. That's why I'm not found of the "synchronous_commit=off" chosen above.
Reading kernel sources trying to understand some more of the performance impact.
Wow! -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
