Re: [PATCH] Store Extension Options

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Store Extension Options
Date: 2014-03-13 20:23:04
Message-ID: CA+TgmoZ9FxDSsQssXTd80DAUmK+SPuSLoKzyAU+OdfBvY_UKYQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 13, 2014 at 11:42 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2014-03-13 11:26:10 -0400, Robert Haas wrote:
>> On Thu, Mar 13, 2014 at 11:11 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> > If there's not a catcache for pg_seclabels, I'd have no objection
>> > to adding one. As for your "userland cache" objection, you certainly
>> > could build such a thing using the existing inval callbacks (if we
>> > had a catcache on pg_seclabels), and in any case what have userland
>> > caches got to do with relcache?
>>
>> I avoided doing that for the same reasons that we've been careful to
>> add no such cache to pg_largeobject_metadata: the number of large
>> objects could be big enough to cause problems with backend memory
>> consumption. Note that large objects are one of the object types to
>> which security labels can be applied, so any concern that applies
>> there also applies here.
>
> Good point.
>
> Are you primarily worried about the size of the cache, or about the size
> of the queued invaldations?

Mostly the former. I can't really see the latter being a big deal. I
mean, if you do a lot of DDL, you'll get more sinval resets, but oh
well. We can't optimize away re-examining the data when it actually is
changing underneath us.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-03-13 20:27:54 Re: [PATCH] Store Extension Options
Previous Message Robert Haas 2014-03-13 20:20:12 Re: [PATCH] Store Extension Options