On 07/15/2015 09:30 PM, Robert Haas wrote:
> On Tue, Jul 14, 2015 at 5:57 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> On 7/7/15 7:07 AM, Andres Freund wrote:
>>> On 2015-07-03 18:03:58 -0400, Tom Lane wrote:
>>>> I have just looked through this thread, and TBH I think we should reject
>>>> this patch altogether --- not RWF, but "no we don't want this". The
>>>> use-case remains hypothetical: no performance numbers showing a
>>>> real-world
>>>> benefit have been exhibited AFAICS.
>>>
>>>
>>> It's not that hard to imagine a performance benefit though? If the
>>> toasted column is accessed infrequently/just after filtering on other
>>> columns (not uncommon) it could very well be beneficial to put the main
>>> table on fast storage (SSD) and the toast table on slow storage
>>> (spinning rust).
>>>
>>> I've seen humoungous toast tables that are barely ever read for tables
>>> that are constantly a couple times in the field.
>>
>> +1. I know of one case where the heap was ~8GB and TOAST was over 400GB.
>
> Yeah, I think that's a good argument for this. I have to admit that
> I'm a bit fatigued by this thread - it started out as a "learn
> PostgreSQL" project, and we iterated through a few design problems
> that made me kind of worried about what sort of state the patch was in
> - and now this patch is more than 4 years old. But if some committer
> still has the energy to go through it in detail and make sure that all
> of the problems have been fixed and that the patch is, as Andreas
> says, in good shape, then I don't see why we shouldn't take it.
I personally think the patch is in a decent shape, and a worthwhile
feature. I agree though with Tom's objections about the pg_dump code.
I do not have enough time or interest right now to fix up this patch
(this is not a feature I personally have a lot of interest in), but if
someone else wishes to I do not think it would be too much work.
Andreas
