> If that's what it looks like your server is running just fine. Load
> of 1.31, 85+% idle, no wait time. Or is that top and vmstat output
> from when the server is running fine?
Don't forget that there are 8 CPUs, and the backend will only run on one
of them.
But I concur that this seems ok.
H
On Fri, 26 Sep 2008, John Huttley wrote:
runningupdate file set perms='0664' took about 10 mins
What do you have checkpoint_segments and shared_buffers set to? If you
want something that's doing lots of updates to perform well, you need to
let PostgreSQL have a decent size chunk of memo
2008/9/25 <[EMAIL PROTECTED]>:
> The result of the top command:
>
> top - 20:44:58 up 5:36, 1 user, load average: 1.31, 1.39, 1.24
> Tasks: 277 total, 2 running, 275 sleeping, 0 stopped, 0 zombie
> Cpu(s): 11.5%us, 2.2%sy, 0.0%ni, 86.3%id, 0.0%wa, 0.0%hi, 0.0%si,
> 0.0%st
> Mem: 3
Hello,
postmaster heavily loads processor. The database is accessed from java
aplication (with several threads), C applications and from PHP scripts.
It seems that one php script, called periodicaly, rises the load but the
script is very simple, something like this:
$var__base = new baza($dbhost
On Thursday 25 September 2008, John Huttley <[EMAIL PROTECTED]> wrote:
>
> Comments anyone?
Don't do full table updates? This is not exactly a news flash.
--
Alan
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.pos
On Thu, Sep 25, 2008 at 1:24 PM, John Huttley <[EMAIL PROTECTED]> wrote:
> I've just had an interesting encounter with the slow full table update
> problem that is inherent with MVCC
>
> The system is 64 bit linux with 2.6.25 kernel feeding scsi disks.
>
> the table is
>
> CREATE TABLE file (
> f
I've just had an interesting encounter with the slow full table update
problem that is inherent with MVCC
The system is 64 bit linux with 2.6.25 kernel feeding scsi disks.
the table is
CREATE TABLE file (
fileid integer NOT NULL,
fileindex integer DEFAULT 0 NOT NULL,
jobid integer NOT
On Thu, 25 Sep 2008, Tom Lane wrote:
Matthew Wakeling <[EMAIL PROTECTED]> writes:
Hi all. I'm having an interesting time performance-wise with a set of indexes.
Any clues as to what is going on or tips to fix it would be appreciated.
Are the indexed columns all the same datatype? (And which t
Matthew Wakeling <[EMAIL PROTECTED]> writes:
> Hi all. I'm having an interesting time performance-wise with a set of
> indexes.
> Any clues as to what is going on or tips to fix it would be appreciated.
Are the indexed columns all the same datatype? (And which type is it?)
It might be helpful
Hi all. I'm having an interesting time performance-wise with a set of indexes.
Any clues as to what is going on or tips to fix it would be appreciated.
My application runs lots of queries along the lines of:
SELECT * from table where field IN (.., .., ..);
There is always an index on the fie
10 matches
Mail list logo
