strange behavior of UPDATE - Mailing list pgsql-hackers

From Edmund Mergl
Subject strange behavior of UPDATE
Date
Msg-id 3745C347.F01A3CAB@bawue.de
Whole thread Raw
Responses Re: [HACKERS] strange behavior of UPDATE  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] strange behavior of UPDATE  (Bruce Momjian <maillist@candle.pha.pa.us>)
Outer joins  (Kaare Rasmussen <kar@webline.dk>)
Re: [HACKERS] strange behavior of UPDATE  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

recently I tried to reproduce some benchmark results
when I discovered a very strange behavior. I did
my tests with the current snapshot of last week,
but other people who have performed the same bench-
mark with postgresql-6.4-2 reported the same problems.

The setup is pretty simple: one table with 13
integer and 7 char(20) columns. For every column
an index is created. The postmaster is started with
-o -F and before each query a 'vacuum analyze' is 
performed.

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.

It would be nice, if this could be fixed.
People from the german UNIX magazine IX
benchmarked Oracle, Informix and Sybase on Linux
and they claimed, that Postgres is totally unusable
because of this problem.

If you need some additional info, just let me know.


Edmund


-- 
Edmund Mergl          mailto:E.Mergl@bawue.de
Im Haldenhau 9        http://www.bawue.de/~mergl
70565 Stuttgart       fon: +49 711 747503
Germany


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Doesn't compile
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] strange behavior of UPDATE