Ben wrote:
I've got a long-running, update-heavy transaction that increasingly
slows down the longer it runs. I would expect that behavior, if there
was some temp file creation going on. But monitoring vmstat over the
life of the transaction shows virtually zero disk activity. Instead, the
Memory usage remains consistent, which is to say that postgres is
using most available system memory all the time, as I configured it
to. There is no swapping going on.
It's not clear to me why forcing a WAL checkpoint would help
anything but it doesn't matter, as only superusers can
Ben wrote:
My transaction calls the same stored procedure many times over. Over the
lifetime of the transaction, that stored procedure slows down by roughly
2 orders of magnitude. The procedure itself tries to look up several
strings in dictionary tables, and if the strings aren't there (most
My transaction calls the same stored procedure many times over. Over
the lifetime of the transaction, that stored procedure slows down by
roughly 2 orders of magnitude. The procedure itself tries to look up
several strings in dictionary tables, and if the strings aren't there
(most of them
On Wed, 1 Nov 2006, Richard Huxton wrote:
1. Avoid updating the same timestamp more than once (if that's happening)
Each row is updated at most once, and not all rows are updated.
2. Update timestamps in one go at the end of the transaction (perhaps by
loading updates into a temp table).
Ben wrote:
On Wed, 1 Nov 2006, Richard Huxton wrote:
1. Avoid updating the same timestamp more than once (if that's happening)
Each row is updated at most once, and not all rows are updated.
2. Update timestamps in one go at the end of the transaction (perhaps
by loading updates into a
I've got a long-running, update-heavy transaction that increasingly slows
down the longer it runs. I would expect that behavior, if there was some
temp file creation going on. But monitoring vmstat over the life of the
transaction shows virtually zero disk activity. Instead, the system has
its
