Re: [HACKERS] row reuse while UPDATE and vacuum analyze problem

Поиск
Список
Период
Сортировка
От The Hermit Hacker
Тема Re: [HACKERS] row reuse while UPDATE and vacuum analyze problem
Дата
Msg-id Pine.BSF.4.05.9907280854190.78452-100000@thelab.hub.org
обсуждение исходный текст
Ответ на row reuse while UPDATE and vacuum analyze problem  (Oleg Bartunov <oleg@sai.msu.su>)
Ответы Re: [HACKERS] row reuse while UPDATE and vacuum analyze problem  (Philip Warner <pjw@rhyme.com.au>)
Re: [HACKERS] row reuse while UPDATE and vacuum analyze problem  (Oleg Bartunov <oleg@sai.msu.su>)
Re: [HACKERS] row reuse while UPDATE and vacuum analyze problem  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список pgsql-hackers
On Wed, 28 Jul 1999, Oleg Bartunov wrote:

> How update performance could be increased if:
>  1. 'vacuum analyze' will analyze index file
>  2. reuse row instead of inserting

Just to clarify, 'reuse row' won't replace inserting (to the best of my
knowledge), only reduce space wastage between vacuum's.  Especially, again
TTBOMK, with MVCC, where each "instance" of a row is serialized.  

Actually, there is a tought...if I understand the concept of MVCC, how is
reusing a row going to work?  My understanding is that I can "physically"
have to copies of a row in a table, one newer then the other.  So, if
someone is running a SELECT while I'm doing an UPDATE, their SELECT will
take the older version of hte row (the row at the time their SELECT
started)...depending on how busy that table is, there will have to be some
sort of mechanism for determining how 'stale' a row is, no?

ie. on a *very* large table, with multiple SELECT/UPDATEs happening?

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 



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

Предыдущее
От: Oleg Bartunov
Дата:
Сообщение: row reuse while UPDATE and vacuum analyze problem
Следующее
От: The Hermit Hacker
Дата:
Сообщение: Re: [HACKERS] Arbitrary tuple size