Re: HOT for PostgreSQL 8.3

On Thu, 2007-02-22 at 00:00 +0530, Pavan Deolasee wrote:
>
> On 2/21/07, Simon Riggs <simon(at)2ndquadrant(dot)com> 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