Re: Frequent Update Project: Design Overview of
От | Hannu Krosing |
---|---|
Тема | Re: Frequent Update Project: Design Overview of |
Дата | |
Msg-id | 1163183892.3071.41.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Frequent Update Project: Design Overview of HOTUpdates ("Simon Riggs" <simon@2ndquadrant.com>) |
Ответы |
Re: Frequent Update Project: Design Overview ofHOTUpdates
|
Список | pgsql-hackers |
Ühel kenal päeval, R, 2006-11-10 kell 12:19, kirjutas Simon Riggs: > On Thu, 2006-11-09 at 18:28 -0500, Tom Lane wrote: > > > 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. > > Also, my understanding was that an overwrite operation could not vary > the length of a tuple (at least according to code comments). But you can change the t_ctid pointer in the heap tuple to point to oldest visible tuple in overflow. What I did not understand very well, is how do you determine, which overflow tuples are safe to remove. Do you mark/remove them when doing the copyback ? > -- ---------------- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com NOTICE: This communication contains privileged or other confidential information. If you have received it in error, please advise the sender by reply email and immediately delete the message and any attachments without copying or disclosing the contents.
В списке pgsql-hackers по дате отправления: