|From:||Bruce Momjian <bruce(at)momjian(dot)us>|
|To:||Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>|
|Cc:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Patch: Write Amplification Reduction Method (WARM)|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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(at)momjian(dot)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
> 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
OK, all my questions have been answered, including the use of flag bits.
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
|Next Message||Andrew Gierth||2017-02-24 17:15:50||Re: Hash support for grouping sets|
|Previous Message||Claudio Freire||2017-02-24 16:40:49||Re: ParallelFinish-hook of FDW/CSP (Re: Steps inside ExecEndGather)|