From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Edmund Mergl <E(dot)Mergl(at)bawue(dot)de> |
Cc: | PostgreSQL Hackers Mailinglist <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] strange behavior of UPDATE |
Date: | 1999-05-24 00:43:33 |
Message-ID: | 28137.927506613@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Edmund Mergl <E(dot)Mergl(at)bawue(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Brett W. McCoy | 1999-05-24 02:26:08 | Re: [GENERAL] Full Text Searches |
Previous Message | Hiroshi Inoue | 1999-05-24 00:23:23 | RE: [HACKERS] Current TODO list |