Please see HOT WIP patch, version 4.1 posted on -patches. here 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 ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
