From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Rod Taylor <pg(at)rbt(dot)ca> |
Cc: | "Wager, Ryan D [NTK]" <Ryan(dot)D(dot)Wager(at)mail(dot)sprint(dot)com>, Postgresql Performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: query rewrite using materialized views |
Date: | 2005-01-04 21:37:27 |
Message-ID: | 200501041337.27884.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Ryan,
> > I do this, PG gets forked many times, it is tough to find the max
> > number of times I can do this, but I have a Proc::Queue Manager Perl
> > driver that handles all of the copy calls. I have a quad CPU machine.
> > Each COPY only hits ones CPU for like 2.1% but anything over about 5
> > kicks the load avg up.
That's consistent with Xeon problems we've seen elsewhere. Keep the # of
processes at or below the # of processors.
Moving pg_xlog is accomplished through:
1) in 8.0, changes to postgresql.conf
(in 8.0 you'd also want to explore using multiple arrays with tablespaces to
make things even faster)
2) in other versions:
a) mount a seperate disk on PGDATA/pg_xlog, or
b) symlink PGDATA/pg_xlog to another location
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2005-01-04 23:20:10 | Re: query rewrite using materialized views |
Previous Message | Christopher Browne | 2005-01-04 19:58:04 | Re: Very Bad Performance. |