On Fri, Feb 24, 2017 at 02:14:23PM +0530, Pavan Deolasee wrote:
> On Thu, Feb 23, 2017 at 11:53 PM, Bruce Momjian <br...@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  <br...@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 +

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to