Please see the attached HOT WIP patch, version 4.1. There are
not any significant changes since the version 4.0 patch that
I posted a week back.
This patch includes some optimizations for efficiently looking
up LP_DELETEd tuples. I have used the recent changes made by
Tom/Heikki which give us few bits per page header. I use one
bit to track if there are any LP_DELETEd tuples in the page.
The changes to this bit are not WAL-logged and hence the
information might not be accurate. But we should be ok with
that.
Another non-trivial change is the addition of logic to clean
up row level fragmentation. I have discussed this earlier on
the list, but neverthless would summarize it again here.
When we reuse LP_DELETEd tuples for UPDATE, we might waste
few bytes when the original size of the reused tuple is
larger than the new tuple. The information about the original
length is lost. When we run out of LP_DELETEd tuples of
size equal or greater than the requested size in UPDATE path,
we correct the row level fragmentation, if any. Please note,
we don't move tuples around and hence don't need the
VACUUM-strength lock on the page.
We use another bit in the page header to track if there are
any fragmented LP_DELETEd tuples in the page. We also need
one bit in the tuple header to track that the particular
tuple was fragmeneted while being reused. This information
is then used when the tuple is again released and marked
LP_DELETE, to update the page level hint bit.
Comments/suggestions ?
Thanks,
Pavan
--
EnterpriseDB http://www.enterprisedb.com
