On Mon, Mar 20, 2017 at 8:11 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Sun, Mar 19, 2017 at 3:05 AM, Pavan Deolasee > <pavan.deola...@gmail.com> wrote: > > On Thu, Mar 16, 2017 at 12:53 PM, Robert Haas <robertmh...@gmail.com> > wrote: > > >> > >> /me scratches head. > >> > >> Aren't pre-warm and post-warm just (better) names for blue and red? > >> > > > > Yeah, sounds better. > > My point here wasn't really about renaming, although I do think > renaming is something that should get done. My point was that you > were saying we need to mark index pointers as common, pre-warm, and > post-warm. But you're pretty much already doing that, I think. I > guess you don't have "common", but you do have "pre-warm" and > "post-warm". > > Ah, I mis-read that. Strictly speaking, we already have common (blue) and post-warm (red), and I just finished renaming them to CLEAR (of WARM bit) and WARM. May be it's still not the best name, but I think it looks better than before. But the larger point is that we don't have an easy to know if an index pointer which was inserted with the original heap tuple (i.e. pre-WARM update) should only return pre-WARM tuples or should it also return post-WARM tuples. Right now we make that decision by looking at the index-keys and discard the pointer whose index-key does not match the ones created from heap-keys. If we need to change that then at every WARM update, we will have to go back to the original pointer and change it's state to pre-warm. That looks more invasive and requires additional index management. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
