Bruce Momjian <[EMAIL PROTECTED]> 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.

> 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?

> 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.

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.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to