From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: toast tables on system catalogs |
Date: | 2011-09-06 02:30:18 |
Message-ID: | CA+TgmobUSXZX7bO_m7Sf35VQ4S0CjzCTVbf6WQu7kmEP=p86Sg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 5, 2011 at 1:01 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Alvaro Herrera wrote:
>> Excerpts from Tom Lane's message of mar mar 01 19:03:35 -0300 2011:
>> > Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
>> > > Strangely, we made pg_database have a toast table, and the only reason
>> > > for this is datacl. Should we create toast tables for the remaining
>> > > catalogs?
>> >
>> > As I commented on your blog, this is nonsense. pg_database has a TOAST
>> > table becase we thought it might need one for datconfig[]. Now that
>> > that's gone, it'd be consistent to remove the toast table, but it didn't
>> > occur to us to do that.
>>
>> Yeah, it occured to me to troll the git logs just after sending the
>> email and I promptly noticed the bug in my conclusion -- there was no
>> datacl back then; and pg_db_role_settings is very new.
>>
>> > aclitem entries wide enough to need toasting are going to suck for all
>> > sorts of reasons (IIRC there are some O(N^2) algorithms in there, not
>> > to mention the cost of pulling in entries from a toast table on every
>> > access) so I am not excited about encouraging people to use them.
>>
>> I agree on not supporting large numbers of privileges, though the error
>> message leaves a bit to be desired.
>>
>> Should we remove the toast table declaration for pg_database?
>>
>> (BTW with the relmapper mechanism, do we still need to declare the toast
>> table OIDs?)
>
> Did we decide on this? Is it a TODO?
Uh, maybe. It's not really clear that there's enough benefit here to
justify someone spending time on it. If no one is feeling motivated
maybe we should just let it go...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-09-06 02:32:56 | Re: savepoint commit performance |
Previous Message | Robert Haas | 2011-09-06 02:27:16 | Re: [v9.1] sepgsql - userspace access vector cache |