From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_class has no toast table? |
Date: | 2010-02-07 17:15:49 |
Message-ID: | 24753.1265562949@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On Sat, 2010-02-06 at 13:04 -0500, Tom Lane wrote:
>> We might still want to consider toast-ifying pg_class if anyone ever
>> complains about not having room for wide relacl values; but CLUSTER
>> shouldn't be a forcing function for such decisions.
> What failure do you get if you have too many relacls or too many
> reloptions? We would want it to fail cleanly. Is it enough to mark those
> columns as MAIN storage?
You'd get a "tuple too large" error if the tuple still didn't fit on a
page after compressing the wide columns. We don't need to do anything
special for that.
> Neither of those is worth worrying about a toast table for. Anybody with
> that long a relacl hasn't thought about their admin structure enough.
Yeah, that's my thought also. You'd likely start having performance
problems with thousand-item ACL lists anyway. You should switch over to
using groups long before that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Boszormenyi Zoltan | 2010-02-07 17:46:18 | Re: [PATCH] Provide rowcount for utility SELECTs |
Previous Message | Tom Lane | 2010-02-07 17:04:57 | Function to return whole relation path? |