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. -- 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
