On Tue, Jul 16, 2013 at 9:00 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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.
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