On Thu, 2007-02-22 at 00:00 +0530, Pavan Deolasee wrote: > > On 2/21/07, Simon Riggs <[EMAIL PROTECTED]> wrote: > > I very much like Hannu's idea, but it does present some > issues. > > > I too liked Hannu's idea initially, but Tom raised a valid concern > that it does not address the basic issue of root tuples. According > to the idea, a DEAD root tuple can be used for a subsequent > update of the same row. For a very large table, even if its updated > frequently, it is not unlikely that the same row might not be updated > for a long time.
That's a fair point and pointer swinging would address that. However, the space wastage is identical to the current situation. We need to choose which use-case we are optimising for: the case you mention would be optimising for high volume but very thinly spread updates. Personally, I don't see that as the most important use case out of the many possibilities. The problem we are trying to address is rows that *are* very frequently updated. There are so many sub-cases its easy to get distracted about which ones are actually causing usage problems right now. Anyway I take the point that pointer swinging is long term necessary, but my question is whether we need this yet. > Even when the update happens we would be > constrained by the length of the new version being same or less > than the root tuple OR ability to perform retail-vacuum of the block. Well, thats a more important question: surely we have agreed that retail VACUUM is both possible and beneficial? > Did you or anybody else got a chance to think about the other idea > I proposed of having indirection from the root line pointer ? Well yes, I saw that, but I was pointing out that we don't need to use just a single byte if we have a part of the tuple header that only exists in these circumstances. > As I > mentioned earlier, I myself haven't thought through it completely, > but at the face of it, it looks doable. It would add a four-byte > overhead per live tuple-chain, but IMHO would be much simpler > to implement and not too invasive. Cool. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
