On Sun, Jul 7, 2013 at 4:34 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-07-07 15:43:17 -0400, Tom Lane wrote:
>> Andres Freund <andres@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
