"Zeugswetter Andreas" <andreas.zeugswetter@telecom.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