- Original Message
From: Greg Smith [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-general@postgresql.org
Sent: Sunday, February 3, 2008 8:43:28 PM
Subject: Re: [GENERAL] Performance problems with Postgresql/ZFS/Non-global
zones on Solaris?
On
Thu,
31
Jan
2008,
[EMAIL PROTECTED
On Thu, 31 Jan 2008, [EMAIL PROTECTED] wrote:
I haven't done any tuning as of yet. I'm running with the default
settings produced by initdb.
The default settings are junk and the disk pattern will change once
they're set correctly, so tuning ZFS first and then PostgreSQL is probably
On Thursday 31 January 2008 07:08, [EMAIL PROTECTED] wrote:
[Following up on my own message.]
Also,
let
us
know
your
wal
tunning
parameters
like
commit_delay,
fsync.
I haven't done any tuning as of yet. I'm running with the default settings
produced by
Don't even bother trying to tune zfs untill after you've tuned postgres,
otherwise your wasting your time.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
As it turns out, I think the ZFS-on-RAID setup I had is the problem[1]. After
running some more I/O tests
Bob,
First, Which exact version of S10 are you using ?
In general, I have seen having logs and data on different pools helps.
Also, let us know your wal tunning parameters like commit_delay, fsync.
If you are using S10u4, setting commit_delay to a non zero number should
help get better
Mayuresh,
comments in-lined, below ...
- Original Message
From: Mayuresh Nirhali [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-general@postgresql.org
Sent: Thursday, January 31, 2008 6:23:23 AM
Subject: Re: [GENERAL] Performance problems with Postgresql/ZFS/Non-global
zones
[Following up on my own message.]
Also,
let
us
know
your
wal
tunning
parameters
like
commit_delay,
fsync.
I haven't done any tuning as of yet. I'm running with the default settings
produced by initdb.
Bob
---(end of
In the hopes that someone has already blazed this trail ...
I'm running Postgresql (v8.1.10) on Solaris 10 (Sparc) from within a non-global
zone. I originally had the database storage in the non-global zone (e.g.
/var/local/pgsql/data on a UFS filesystem) and was getting performance of X
