Re: Indirect indexes - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: Indirect indexes
Date
Msg-id CABOikdNxQxGbU0svtFzn4Bi34rTM6-L_vJpFVZ8Ln5bBQnQcPg@mail.gmail.com
Whole thread Raw
In response to Re: Indirect indexes  (Petr Jelinek <petr@2ndquadrant.com>)
Responses Re: Indirect indexes  (Claudio Freire <klaussfreire@gmail.com>)
Re: Indirect indexes  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers


On Thu, Oct 20, 2016 at 8:44 PM, Petr Jelinek <petr@2ndquadrant.com> wrote:


WARM can do WARM update 50% of time, indirect index can do HOT update
100% of time (provided the column is not changed), I don't see why we
could not have both solutions.


I think the reason why I restricted WARM to one update per chain, also applies to indirect index. For example, if a indirect column value is changed from 'a' to 'b' and back to 'a', there will be two pointers from 'a' to the PK and AFAICS that would lead to the same duplicate scan issue.

We have a design to convert WARM chains back to HOT and that will increase the percentage of WARM updates much beyond 50%. I was waiting for feedback on the basic patch before putting in more efforts, but it went unnoticed last CF.
 
That all being said, it would be interesting to hear Álvaro's thoughts
about which use-cases he expects indirect indexes to work better than WARM.


Yes, will be interesting to see that comparison. May be we need both or may be just one. Even better may be they complement each other.. I'll also put in some thoughts in this area. 

Thanks,
Pavan

--
 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-hackers by date:

Previous
From: Claudio Freire
Date:
Subject: Re: Indirect indexes
Next
From: Tomas Vondra
Date:
Subject: Re: Speed up Clog Access by increasing CLOG buffers