Re: Very long execution time of "select nextval('..');" - Mailing list pgsql-general

From mljv@planwerk6.de
Subject Re: Very long execution time of "select nextval('..');"
Date
Msg-id 200802021509.42006.mljv@planwerk6.de
Whole thread Raw
In response to Re: Very long execution time of "select nextval('..');"  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Hi Greg, hi Tom,

Am Sonntag, 27. Januar 2008 22:44 schrieb Tom Lane:
> mljv@planwerk6.de writes:
> > ok, at the moment i got some traffic and my load is at 1.5. But now with
> > logging the timestamp I have seen that the long durations are quite
> > regular at intervals of 10 minutes.
>
> Well, that's pretty suggestive.  Tell us about your checkpoint and
> bgwriter settings.  Also, is there any other service running on the
> machine that might have activity spikes every 10 minutes?

thanks for your suggestions and the very detail explanation.

i pretty much solved my problem. i changed the checkpoint and bg_writer
settings, but what was much more important, i droped one Job who did some bad
stuff. This job did update some rows on certain situations. these situation
came to often so this job was updating all the time.

I never ment to blame postgresql for my trouble as i work with it for years
and i am pretty sure that postgresql is doing an excelent job. i 've got to
blame me for this bad programming.

thanks a lot for helping as this checkpoint discussion opened my mind for the
real problem which was not easy to see (at least for me).

But one more question to my problem: Before i solved it i saw some statements
which say "SELECT waiting" in the process table (ps ax)

i thought "waiting" means some kind of database lock (row or table lock). Is
it true? If not, what other conditions can occur if a process says "SELECT
waiting"? Can it mean "Disk/IO Waiting" or "Network IO waiting"?

kind regrads
Janning


pgsql-general by date:

Previous
From: vladimir konrad
Date:
Subject: Re: [OT] "advanced" database design (long)
Next
From: Lewis Cunningham
Date:
Subject: Re: [OT] "advanced" database design (long)