Performance block size.

From: Tory M Blue <tmblue(at)gmail(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Performance block size.
Date: 2011-05-26 22:34:55
Message-ID: BANLkTimwU7q77JTdU3GH4hCwD5rXopt+SA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Working on some optimization as well as finally getting off my
backside and moving us to 64bit (32gb+memory).

I was reading and at some point it appears on freeBSD the Postgres
block size was upped to 16kb, from 8kb. And on my fedora systems I
believe the default build is 8kb.

When we were using ext2/ext3 etc made not much of a difference as far
as I can tell since one was limited to 4kb at the file system (so 2
disk access for every Postgres write/read ??).

Now with ext4, we can set the block size, so would it make sense for
larger data sets, that end up loading the entire 5 million row table
into memory, to have a larger block size, or matching block size
between postgres and the filesystem (given that raid is configured to
optimize the writes over all the spindles in your storage?) (leaving
that piece alone).

I want to focus on the relation of Postgres default block size, and
what the various issues/gains are with upping it , at the same time
matching or doing some storage magic to figure out the optimum between
Postgres/filesystem?

Trying to gain some performance and wondered if any of this tuning
even is something I should bother with.

Fedora f12 (looking at CentOS)
postgres 8.4.4 (probably time to start getting to 9.x)
slon 1.2.20 (same, needs an update)

But system tuning, 64 bit first..

Thanks
Tory

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Mark Kirkwood 2011-05-26 22:43:25 Re: serveRAID M5014 SAS
Previous Message Cédric Villemain 2011-05-26 18:13:22 Re: Hash Anti Join performance degradation