Re: Frequent Update Project: Design Overview of HOTUpdates

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas ADI SD
Тема Re: Frequent Update Project: Design Overview of HOTUpdates
Дата
Msg-id E1539E0ED7043848906A8FF995BDA579017C0930@m0143.s-mxs.net
обсуждение исходный текст
Ответ на Re: Frequent Update Project: Design Overview of HOTUpdates  (NikhilS <nikkhils@gmail.com>)
Ответы Re: Frequent Update Project: Design Overview of HOTUpdates  (NikhilS <nikkhils@gmail.com>)
Re: Frequent Update Project: Design Overview ofHOTUpdates  ("Simon Riggs" <simon@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: "Zeugswetter Andreas ADI SD"
Дата:
Сообщение: Re: Frequent Update Project: Design Overview of HOTUpdates
Следующее
От: "Simon Riggs"
Дата:
Сообщение: Re: Frequent Update Project: Design Overview ofHOTUpdates