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: http://www.postgresql.org/mailpref/pgsql-hackers
