From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Zeugswetter Andreas" <andreas(dot)zeugswetter(at)telecom(dot)at> |
Cc: | "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "'PostgreSQL Development'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: AW: AW: Proposal for enhancements of privilege system |
Date: | 2000-06-04 18:47:40 |
Message-ID: | 6434.960144460@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Zeugswetter Andreas" <andreas(dot)zeugswetter(at)telecom(dot)at> writes:
>> Exactly, that's why I have to do it like this. To interface a system
>> catalog to the shared cache you need a primary key, which would be
>> (object, user, action) in my proposal. With that setup I can easily make
>> queries of the sort "does user X have select right on table Y" as fast as
>> possible, no slower than, say, looking up an attribute definition in
>> pg_attribute.
> Ok, I see that you will somtimes want to do a select like that, only I do
> not see the reason why this has to be the primary target for speed.
> Remember that for each row in the db you have >30 bytes of overhead
> (I forgot the exact number) plus table_oid + user_oid thus if a user has
> all permissions on a table, that will take 300 bytes.
> I also think that a key of object + {user|group} is imho selective enough,
> you don't want a key whose only info is a boolean.
I tend to agree with Andreas on this: having a separate tuple for each
individual kind of access right will consume an unreasonable amount of
space --- both on disk and in the syscache, if a cache is used for this
table. (In the cache, that translates to entries not living very long
before they fall off the LRU list.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-06-04 18:57:06 | Re: PG 7.0 crash on SELECT |
Previous Message | Tom Lane | 2000-06-04 18:41:06 | Re: 7.0.1 Problems. |