Search Postgresql Archives

Re: Very long execution time of "select nextval('..');"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



mljv@xxxxxxxxxxxx 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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux