Edmund Mergl <E.Mergl@bawue.de> writes:
> When loading 100.000 rows into the table everything works ok. Selects
> and updates are reasonable fast. But when loading 1.000.000 rows the
> select statements still work, but a simple update statement shows this
> strange behavior. A never ending disk-activity starts. Memory
> consumption increases up to the physical limit (384 MB) whereas the
> postmaster uses only a few % of CPU time. After 1 hour I killed the
> post-master.
I tried to reproduce this with current sources on a rather underpowered
Linux box (64Mb of memory, about 40Mb of which is locked down by a
high-priority data collection process). It took a *long* time, but
as far as I could see it was all disk activity, and that's hardly
surprising given the drastic shortage of buffer cache memory.
In particular I did not see any dramatic growth in the size of the
backend process. The test case
update bench set k500k = k500k + 1 where k100 = 30;
required a maximum of 10Mb.
Perhaps you could try it again with a current 6.5 snapshot and see
whether things are any better?
Also, I suspect that increasing the postmaster -B setting beyond its
default of 64 would be quite helpful.
regards, tom lane
