On Wed, 2007-04-04 at 16:26 -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Simon Riggs wrote:
> >> Having both default GUC and individual table-level WITH parameters seems
> >> like the best way to me.
>
> > Agreed.
>
> There's an extremely good reason not to have a GUC variable, which is
> that changes in it would fail to reflect into decisions about whether to
> create TOAST tables. When I first brought up the point I didn't see a
> way around it, but now that I do, I don't think we should expose a
> failure mode just to have a GUC.
It depends how it works. If the GUC was a default that was applied only
at CREATE TABLE time, then it would be safe.
Changing default_with_oids didn't cause all tables to stop/start using
oids. Why would it?
> > OK, but we need to throw a clear message when the TOAST table needs to
> > be created by the administrator.
>
> No, we just need to not have a GUC for this. There's no GUC for default
> fill factor; have you seen anyone complain about that?
I'd rather set it once than many times, thats all.
I certainly care more about temp_tablespaces than I do about this GUC...
that is something I'll be moaning about if that gets deferred.
> > The big question is whether this is for 8.3 or 8.4.
>
> What I would definitely like to see for 8.3 is some performance testing
> done to determine whether we ought to change the current defaults.
> (Both TOAST_TUPLES_PER_PAGE and EXTERN_TUPLES_PER_PAGE ought to be looked
> at.)
>
> Whether it's possible to get the storage parameter in there depends on
> how soon someone produces a patch. Given that we understand this area
> fairly well, I personally would be willing to give it a pass on the
> "feature freeze" rule, as long as we have the patch by say mid-April.
I meant to say a clear "yes" to that, but I've other business stuff for
two weeks in mid-April so I'll need to rely on colleagues to take up the
challenge.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com