On 9/17/07, Tom Lane [EMAIL PROTECTED] wrote:
Yeah. As the code stands, anything that's XMIN_INVALID will be
considered not-HotUpdated (look at the macro...). So far I've seen no
place where there is any value in following a HOT chain past such a
tuple --- do you see any?
No, I don't
On 9/17/07, Tom Lane [EMAIL PROTECTED] wrote:
Meanwhile I've started looking at the vacuum code, and it seems that v16
has made that part of the patch significantly worse. VACUUM will fail
to count tuples that are removed by pruning, which seems like something
it should report somehow.
I
On 9/16/07, Tom Lane [EMAIL PROTECTED] wrote:
Attached is as far as I've gotten with reviewing the HOT patch; I see
that Pavan is still fooling with it so we'd better re-sync.
I am done with most of the items on my plate. I was not sure how
far you have gone with the patch, so was trying to
Pavan Deolasee [EMAIL PROTECTED] writes:
I liked those changes. I am wondering if we could have avoided
duplicating the chain following code in heap_hot_search_buffer and
index_getnext.
I wasn't totally thrilled with duplicating that code, but the callers of
heap_hot_search are only interested
On 9/16/07, Tom Lane [EMAIL PROTECTED] wrote:
BTW, I'm in process of taking out the separate HEAPTUPLE_DEAD_CHAIN
return value from HeapTupleSatisfiesVacuum.
I agree. I myself suggested doing so earlier in the discussion (I actually
even removed this before I sent out the add-on patch last
BTW, I am still looking for a reason for the hard-prune logic to live.
It seems to complicate matters far more than it's worth --- in
particular the way that the WAL replay representation is set up seems
confusing and fragile. (If prune_hard is set, the redirect entries
mean something completely
On 9/16/07, Tom Lane [EMAIL PROTECTED] wrote:
Something else I was just looking at: in the pruning logic, SetRedirect
and SetDead operations are done at the same time that we record them for
the eventual WAL record creation, but SetUnused operations are
postponed and only done at the end.
Pavan Deolasee [EMAIL PROTECTED] writes:
So are you suggesting we go back to the earlier way of handling
aborted tuples separately ? But then we can not do that by simply
checking for !HeaptupleIsHotUpdated. There could be several aborted
tuples at the end of the chain of which all but one are
