Re: Frequent Update Project: Design Overview of HOTUpdates - Mailing list pgsql-hackers

From Zeugswetter Andreas ADI SD
Subject Re: Frequent Update Project: Design Overview of HOTUpdates
Date
Msg-id E1539E0ED7043848906A8FF995BDA579017C0930@m0143.s-mxs.net
Whole thread Raw
In response to Re: Frequent Update Project: Design Overview of HOTUpdates  (NikhilS <nikkhils@gmail.com>)
Responses Re: Frequent Update Project: Design Overview of HOTUpdates  (NikhilS <nikkhils@gmail.com>)
Re: Frequent Update Project: Design Overview ofHOTUpdates  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-hackers
> > 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 ?
> 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)

Andreas


pgsql-hackers by date:

Previous
From: "Zeugswetter Andreas ADI SD"
Date:
Subject: Re: Frequent Update Project: Design Overview of HOTUpdates
Next
From: "Simon Riggs"
Date:
Subject: Re: Frequent Update Project: Design Overview ofHOTUpdates