strange behavior of UPDATE

Поиск
Список
Период
Сортировка
От Edmund Mergl
Тема strange behavior of UPDATE
Дата
Msg-id 3745C347.F01A3CAB@bawue.de
обсуждение исходный текст
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Doesn't compile
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] strange behavior of UPDATE