Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)
Дата
Msg-id 20170224165816.GB23209@momjian.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Список pgsql-hackers
On Fri, Feb 24, 2017 at 02:14:23PM +0530, Pavan Deolasee wrote:
> 
> 
> On Thu, Feb 23, 2017 at 11:53 PM, Bruce Momjian <bruce@momjian.us> wrote:
> 
>     On Thu, Feb 23, 2017 at 03:03:39PM -0300, Alvaro Herrera wrote:
>     > Bruce Momjian wrote:
>     >
>     > > As I remember, WARM only allows
>     > > a single index-column change in the chain.  Why are you seeing such a
>     > > large performance improvement?  I would have thought it would be that
>     > > high if we allowed an unlimited number of index changes in the chain.
>     >
>     > The second update in a chain creates another non-warm-updated tuple, so
>     > the third update can be a warm update again, and so on.
> 
>     Right, before this patch they would be two independent HOT chains.  It
>     still seems like an unexpectedly-high performance win.  Are two
>     independent HOT chains that much more expensive than joining them via
>     WARM?
> 
> 
> In these tests, there are zero HOT updates, since every update modifies some
> index column. With WARM, we could reduce regular updates to half, even when we
> allow only one WARM update per chain (chain really has a single tuple for this
> discussion). IOW approximately half updates insert new index entry in *every*
> index and half updates 
> insert new index entry *only* in affected index. That itself does a good bit
> for performance.
> 
> So to answer your question: yes, joining two HOT chains via WARM is much
> cheaper because it results in creating new index entries just for affected
> indexes.

OK, all my questions have been answered, including the use of flag bits.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps inside ExecEndGather)
Следующее
От: Andrew Gierth
Дата:
Сообщение: Re: [HACKERS] Hash support for grouping sets