On Tue, Mar 28, 2017 at 7:49 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Mon, Mar 27, 2017 at 04:29:56PM -0400, Robert Haas wrote: > On Thu, Mar 23, 2017 at 2:47 PM, Pavan Deolasee > <pavan.deolasee@gmail.com> wrote: > > It's quite hard to say that until we see many more benchmarks. As author of > > the patch, I might have got repetitive with my benchmarks. But I've seen > > over 50% improvement in TPS even without chain conversion (6 indexes on a 12 > > column table test). > > This seems quite mystifying. What can account for such a large > performance difference in such a pessimal scenario? It seems to me > that without chain conversion, WARM can only apply to each row once > and therefore no sustained performance improvement should be possible > -- unless rows are regularly being moved to new blocks, in which case > those updates would "reset" the ability to again perform an update. > However, one would hope that most updates get done within a single > block, so that the row-moves-to-new-block case wouldn't happen very > often. > > I'm perplexed.
Just to add more to what I just said in another email, note that HOT/WARM chains are created when a new root line pointer is created in the heap (a line pointer that has an index pointing to it). And a new root line pointer is created when a non-HOT/non-WARM update is performed. As soon as you do a non-HOT/non-WARM update, the next update can again be a WARM update even when everything fits in a single block.
That's why for a workload which doesn't do HOT updates and where not all index keys are updated, you'll find every alternate update to a row to be a WARM update, even when there is no chain conversion. That itself can save lots of index bloat, reduce IO on the index and WAL.
Let me know if its still not clear and I can draw some diagrams to explain it.
