From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | mljv(at)planwerk6(dot)de |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Very long execution time of "select nextval('..');" |
Date: | 2008-01-27 17:56:49 |
Message-ID: | 26171.1201456609@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
mljv(at)planwerk6(dot)de writes:
> we run postgresql-8.1 on a dedicated debian box 64bit, dual-core CPU, 8GB RAM,
> RAID-1.
8.1.what?
> LOG: duration: 12636.746 ms statement: EXECUTE <unnamed> [PREPARE: select
> nextval ('member_id_seq')]
That's just bizarre, especially if your system isn't showing any other
signs of stress.
> Unfortunatly i can not tell at which time this happens as the log doesn't
> show the time of day.
See log_line_prefix. I think what you need to do is gather some
evidence about what else is happening at the same time --- can you
afford to enable log_statement = all? Also, you should try to correlate
this with spikes in I/O demand (try running "vmstat 1" or similar).
It could be that this is related to checkpointing, which you won't see
in a log_statement trace. In 8.1 you'd have to crank up
log_min_messages to DEBUG2 to get log entries for checkpoint start and
end, which is going to result in a mighty verbose log, but you may have
to do that to confirm or disprove the idea.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Ginsburg | 2008-01-27 18:56:18 | Re: A select DISTINCT query? - followup Q |
Previous Message | Phil Rhoades | 2008-01-27 17:33:12 | Re: A select DISTINCT query? - followup Q |