TOAST Threshold? Re: Status of 8.3 patches

jd(at)commandprompt(dot)com ("Joshua D. Drake") writes:
> Alvaro Herrera wrote:
>> Joshua D. Drake wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Heikki Linnakangas wrote:
>>>> Joshua D. Drake wrote:
>
>>> I guess my point is, if the patch looks good and does not appear
>>> to hurt anything, why not apply it? At least that way we can start
>>> to review the progress of the feature itself as it starts to see
>>> use.
>>
>> Yeah, you mean like commit_delay. It really worked great, that
>> reviewing of a feature, you know. It only took 3 years until
>> someone realized that it didn't work as advertised.
>
> You can not compare the relevant smallness of use from three years
> ago to the explosion of use at present. It is certainly unfortunate
> that commit_delay didn't work as advertised, but then again had we
> not applied it, we would have never known in the first place and now
> we have the opportunity to fix or remove it.
>
> You can compare other such features that many people don't touch
> that are starting to show promise over time such as cpu_tuple_cost.

I'd like to see a bit more available for the TOAST threshold, even if
only a little bit of documentation to make it an unscary thing to
modify the threshold so that I could recommend that our DBAs modify
it, and *not* have them get all hinky at the fact that I'm telling
them to touch the sources.

"Yes, I'm telling you to modify the sources. It's a safe
modification - see? The documentation says so!"

Without this, I'll have to fight some ghastly uphill battle in order
to get this set in our builds, and I *don't* want to wait until 8.4 to
see our ~900 byte long XML values TOASTed.

I'd be happy to help make the patch.
--
(reverse (concatenate 'string "ofni.secnanifxunil" "@" "enworbbc"))
http://cbbrowne.com/info/linux.html
:FATAL ERROR -- VECTOR OUT OF HILBERT SPACE