On Thu, Aug 4, 2016 at 02:35:32PM -0300, Claudio Freire wrote: > > Vacuum will need to be taught not to break the invariant, but I > > believe this is viable and efficient. > > > And I didn't mention the invariant. > > The invariant would be that all WARM chains: > > * contain entire HOT chains (ie: no item pointers pointing to the > middle of a HOT chain)
You mean no _index_ item pointers, right? > * start at the item pointer, and end when the t_ctid of the heap > tuple either points to another page, or a tuple with a different index > key Uh, there is only one visible tuple in a HOT chain, so I don't see the different index key as being a significant check. That is, I think we should check the visibility first, as we do now, and then, for the only-visible tuple, check the key. I don't see a value in (expensive) checking the key of an invisible tuple in hopes of stoping the HOT chain traversal. Also, what happens when a tuple chain goes off-page, then returns to the original page? That is a new HOT chain given our current code, but would the new tuple addition realize it needs to create a new index tuple? The new tuple code needs to check the index's root HOT tid for a non-match. > This is maintained by: > > * No item pointer will be created for row versions whose immediately > previous version is already on the index with the same key You really only have the ctid HOT head stored in the index, not the immediate ctid. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
