Re: [HACKERS] UPDATE performance degradation (6.5.1)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] UPDATE performance degradation (6.5.1)
Дата
Msg-id 7070.933086380@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] UPDATE performance degradation (6.5.1)  (Oleg Bartunov <oleg@sai.msu.su>)
Ответы Re: [HACKERS] UPDATE performance degradation (6.5.1)  (Oleg Bartunov <oleg@sai.msu.su>)
Список pgsql-hackers
Oleg Bartunov <oleg@sai.msu.su> writes:
> Probably I found the problem. After running my test, whiich  became
> very slow I looked at /usr/local/pgsql/data/base/discovery

> -rw-------   1 postgres users     5070848 Jul 27 16:14 hits
> -rw-------   1 postgres users     1409024 Jul 27 16:14 hits_pkey

> This is for table with one row  after a lot of updates.
> Too much. vacuum analyze this table was a good  medicine !

If the table contains only one row, why are you bothering with an
index on it?

> Is this a design problem ? 

Only that space in tables and indexes can't be re-used until vacuum.
I'm not sure if there's any good way around that or not...
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: wieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: fmgr interface [was: plperl inital pass]
Следующее
От: Thomas Lockhart
Дата:
Сообщение: i386 RPMs available for v6.5.1