Hi
Dennis,
I am
just cusrios to try PG with different block sizes ;) I don't
know how much performance the bigger block size will bring (I mean 32k
or 64k , for example, for DWH applikations).
I am
surprised to hear that OCFS2.0 (or any her FS usind direct I/O) performs
well with PG. A month ago I have performed a simple test
with Veritas FS, with and than without cache (e.g. direct
I/O). I have started 1 , then 2, , then 3,
then 4 parallel INSERT processes.
Veritas FS WITH FS cache outperformed the direct I/O version by
factor 2-2.5 !
I
haven't tested woth OCFS2.0 though. I am not sure that OCFS2.0 is the good
choice for PG data and index
filesystems.
For
WAL -> perhaps.
Best
Regards. Milen
-----Original Message-----
From: pgsql-performance-owner@xxxxxxxxxxxxxx [mailto:pgsql-performance-owner@xxxxxxxxxxxxxx] On Behalf Of Denis Lussier
Sent: Thursday, August 03, 2006 7:36 AM
To: Luke Lonergan
Cc: Milen Kulev; pgsql-performance@xxxxxxxxxxxxxx
Subject: Re: [PERFORM] XFS filessystem for Datawarehousing -2
I was kinda thinking that making the Block Size configurable at InitDB time would be a nice & simple enhancement for PG 8.3. My own personal rule of thumb for sizing is 8k for OLTP, 16k for mixed use, & 32k for DWH.
I have no personal experience with XFS, but, I've seen numerous internal edb-postgres test results that show that of all file systems... OCFS 2.0 seems to be quite good for PG update intensive apps (especially on 64 bit machines).
On 8/1/06, Luke Lonergan <llonergan@xxxxxxxxxxxxx> wrote:Milen,
On 8/1/06 3:19 PM, "Milen Kulev" <makulev@xxxxxxx> wrote:
> Sorry, forgot to ask:
> What is the recommended/best PG block size for DWH database? 16k, 32k, 64k
> ?
> What hsould be the relation between XFS/RAID stripe size and PG block size ?
We have found that the page size in PG starts to matter only at very high
disk performance levels around 1000MB/s. Other posters have talked about
maintenance tasks improving in performance, but I haven't seen it.
- Luke
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
