Re: Frequent Update Project: Design Overview of HOTUpdates

>
> Hi,

> > This allows the length of a typical tuple chain to be extremely short in
> > > practice. For a single connection issuing a stream of UPDATEs the
> chain
> > > length will no more than 1 at any time.
> >
> > Only if there are no other transactions being held open, which makes
> > this claim a lot weaker.
>
> 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 roughly 170% improvement with the
HOT update patch over BETA2.

In case of BETA2, since all versions are in the main heap, we end up
doing multiple index scans for them. In case of HOT updates, we have a
single index entry with the chains getting traversed from the overflow
relation. So as Simon has mentioned the need to avoid long chains remains
a difficulty for both the situations.

Regards,
Nikhils

--
EnterpriseDB http://www.enterprisedb.com