On Tue, Jul 16, 2013 at 9:00 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Sun, Jul 7, 2013 at 4:34 PM, Andres Freund <and...@2ndquadrant.com> wrote: >> On 2013-07-07 15:43:17 -0400, Tom Lane wrote: >>> Andres Freund <and...@2ndquadrant.com> writes: >>> > 3b) Add catcache 'filter' that ensures the cache stays unique and use >>> > that for the mapping >>> >>> > I slightly prefer 3b) because it's smaller, what's your opinions? >>> >>> This is just another variation on the theme of kluging the catcache to >>> do something it shouldn't. You're still building a catcache on a >>> non-unique index, and that is going to lead to trouble. >> >> I don't think the lurking dangers really are present. The index >> essentially *is* unique since we filter away anything non-unique. The >> catcache code hardly can be confused by tuples it never sees. That would >> even work if we started preloading catcaches by doing scans of the >> entire underlying relation or by caching all of a page when reading one >> of its tuples. >> >> I can definitely see that there are "aesthetical" reasons against doing >> 3b), that's why I've also done 3a). So I'll chalk you up to voting for >> that... > > I also vote for (3a). I did a quick once over of 1, 2, and 3a and > they look reasonable. Barring strenuous objections, I'd like to go > ahead and commit these, or perhaps an updated version of them.
Hearing no objections, I have done this. Per off-list discussion with Andres, I also included patch 4, which gives us regression test coverage for this code, and have fixed a few bugs and a bunch of stylistic things that bugged me. -- 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
