From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: changeset generation v5-01 - Patches & git tree |
Date: | 2013-07-07 20:34:31 |
Message-ID: | 20130707203431.GD2062@alap2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2013-07-07 15:43:17 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2013-07-07 20:50:22 | Re: [PATCH] Add session_preload_libraries configuration parameter |
Previous Message | Szymon Guz | 2013-07-07 20:20:37 | Re: [COMMITTERS] pgsql: PL/Python: Convert numeric to Decimal |