Re: Frequent Update Project: Design Overview of HOTUpdates

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Frequent Update Project: Design Overview of HOTUpdates
Дата
Msg-id 455472B3.6000706@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Frequent Update Project: Design Overview of HOTUpdates  ("Simon Riggs" <simon@2ndquadrant.com>)
Список pgsql-hackers
Oops, pressed send too early. Ignore the one-line reply I just sent...

Simon Riggs wrote:
> On Thu, 2006-11-09 at 18:28 -0500, Tom Lane wrote:
>> "Simon Riggs" <simon@2ndquadrant.com> writes:
>>> HOT can only work in cases where a tuple does not modify one of the
>>> columns defined in an index on the table, and when we do not alter the
>>> row length of the tuple.
>> Seems like "altering the row length" isn't the issue, it's just "is
>> there room on the page for the new version".  Again, a generous
>> fillfactor would give you more flexibility.
> 
> The copy-back operation can only work if the tuple fits in the same
> space as the root tuple. If it doesn't you end up with a tuple
> permanently in the overflow relation. That might not worry us, I guess.

You can't move tuples around in a page without holding a Vacuum lock on 
the page. Some other backend might have the page pinned and have a 
pointer to a tuple on the page that would get bogus if the tuple is 
moved. Maybe you could try to get a vacuum lock when doing the update 
and prereserve space for the new version if you can get one.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


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

Предыдущее
От: "Heikki Linnakangas"
Дата:
Сообщение: Re: Frequent Update Project: Design Overview of HOTUpdates
Следующее
От: Gregory Stark
Дата:
Сообщение: Re: Frequent Update Project: Design Overview of HOT Updates