Re: Very long execution time of "select nextval('..');"
От | Tom Lane |
---|---|
Тема | Re: Very long execution time of "select nextval('..');" |
Дата | |
Msg-id | 26171.1201456609@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Very long execution time of "select nextval('..');" (mljv@planwerk6.de) |
Ответы |
Re: Very long execution time of "select nextval('..');"
|
Список | pgsql-general |
mljv@planwerk6.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
В списке pgsql-general по дате отправления: