On Fri, 2006-11-10 at 17:04 +0100, Zeugswetter Andreas ADI SD wrote:
> > > True, but Nikhil has run tests that clearly show HOT outperforming
> > > current situation in the case of long running transactions. The need
>
> > > to optimise HeapTupleSatisfiesVacuum() and avoid long chains does
> > > still remain a difficulty for both HOT and the current situation.
> >
> >
> > Yes, I carried out some pgbench runs comparing our current
> > HOT update patch with PG82BETA2 sources for the long running
> > transaction case. For an apples to apples comparison we got
>
> Vaccuums every 5 minutes, or no vaccuums ?
Same either way, since vacuum would not remove any tuples.
> > roughly 170% improvement with the HOT update patch over BETA2.
>
> Wow, must be smaller indexes and generally less index maintenance.
> What this also states imho, is that following tuple chains
> is not so expensive as maintaining indexes (at least in a heavy update
> scenario like pgbench).
>
> Maybe we should try a version, where the only difference to now is,
> that when the index keys stay the same the indexes are not updated, and
> the tuple
> chain is followed instead when selecting with index. (Maybe like the
> current alive flag the index pointer can even be refreshed to the oldest
> visible
> tuple by readers)
I think that is SITC, nearly.
It's also exactly what HOT does, with the exception that the updated
tuples goes to a block in the overflow, rather than a block later in the
heap. The overflow relation isn't critical to the HOT mechanism, but it
does allow the two optimisations of not requiring all tuple headers to
be modified with the back pointer and improving the locality of VACUUM.
We might do that with some other structuring, but if it works for TOAST,
I figure its OK for HOT also.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com
