Re: Drop in performance for each INSERT/DELETE combo

Поиск
Список
Период
Сортировка
От Turbo Fredriksson
Тема Re: Drop in performance for each INSERT/DELETE combo
Дата
Msg-id 87it893blc.fsf@papadoc.bayour.com
обсуждение исходный текст
Ответ на Drop in performance for each INSERT/DELETE combo  (Turbo Fredriksson <turbo@bayour.com>)
Список pgsql-hackers
[let's keep this thread on the list please]

>>>>> "Nikolay" == Nikolay Mihaylov <pg@nmmm.nu> writes:
   Nikolay> Why you do not use UPDATE instead DELETE ? (e.g. flag if   Nikolay> the operation is finished)

That was my first response when the test crew said that 'they found
that the problem seemed to be in the DELETE, not the INSERT' (their
exact words :).

My idea was that that would decrease the fragmentation of the database...

The difference was minor, (yet again) according to the test crew...
   Nikolay> We had similar problems, but a VACUUM once per 2-3 mo,   Nikolay> helps us (the database is not so big ~ 20
-30MB).
 

Is this database constantly changing? Or is it more or less static?

The database won't be bigger than 10Mb at any time (and that's an
exaggeration). The real issue seem to be the constant changing of
the content...
-- 
Uzi Ortega 767 class struggle Clinton counter-intelligence
arrangements toluene PLO AK-47 Ft. Meade Soviet quiche Khaddafi
cracking
[See http://www.aclu.org/echelonwatch/index.html for more about this]


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

Предыдущее
От: Thomas Lockhart
Дата:
Сообщение: Re: Mandrake RPMs rebuilt
Следующее
От: Turbo Fredriksson
Дата:
Сообщение: Re: Postgresql backend to perform vacuum automatically