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
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@greenplum.com> wrote:Milen,
On 8/1/06 3:19 PM, "Milen Kulev" <makulev@gmx.net> 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