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: >> On Wed, Mar 15, 2017 at 3:44 PM, Pavan Deolasee >> <pavan.deola...@gmail.com> wrote: >> > I couldn't find a better way without a lot of complex infrastructure. >> > Even >> > though we now have ability to mark index pointers and we know that a >> > given >> > pointer either points to the pre-WARM chain or post-WARM chain, this >> > does >> > not solve the case when an index does not receive a new entry. In that >> > case, >> > both pre-WARM and post-WARM tuples are reachable via the same old index >> > pointer. The only way we could deal with this is to mark index pointers >> > as >> > "common", "pre-warm" and "post-warm". But that would require us to >> > update >> > the old pointer's state from "common" to "pre-warm" for the index whose >> > keys >> > are being updated. May be it's doable, but might be more complex than >> > the >> > current approach. >> >> /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". -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers