On Wed, Apr 5, 2017 at 2:32 PM, Pavan Deolasee <pavan.deola...@gmail.com> wrote: >> The only other idea that I have for a really clean solution here is to >> support this only for index types that are amcanreturn, and actually >> compare the value stored in the index tuple with the one stored in the >> heap tuple, ensuring that new index tuples are inserted whenever they >> don't match and then using the exact same test to determine the >> applicability of a given index pointer to a given heap tuple. > > Just so that I understand, are you suggesting that while inserting WARM > index pointers, we check if the new index tuple will look exactly the same > as the old index tuple and not insert a duplicate pointer at all?
Yes. > I considered that, but it will require us to do an index lookup during WARM > index insert and for non-unique keys, that may or may not be exactly cheap. I don't think it requires that. You should be able to figure out based on the tuple being updated and the corresponding new tuple whether this will bet true or not. > Or we need something like what Claudio wrote to sort all index entries by > heap TIDs. If we do that, then the recheck can be done just based on the > index and heap flags (because we can then turn the old index pointer into a > CLEAR pointer. Index pointer is set to COMMON during initial insert). Yeah, I think that patch is going to be needed for some of the storage work I'm interesting in doing, too, so I am tentatively in favor of it, but I wasn't proposing using it here. > The other way is to pass old tuple values along with the new tuple values to > amwarminsert, build index tuples and then do a comparison. For duplicate > index tuples, skip WARM inserts. This is more what I was thinking. But maybe one of the other ideas you wrote here is better; not sure. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers