Re: patch : Allow toast tables to be moved to a different tablespace

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andreas Karlsson <andreas(at)proxel(dot)se>, Julien Tachoires <julmon(at)gmail(dot)com>, Alex Shulgin <ash(at)commandprompt(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: patch : Allow toast tables to be moved to a different tablespace
Date: 2015-07-15 19:30:15
Message-ID: CA+TgmoZB9vY+QMOSJaH8wtR6dLM_1WKjBFPJ1PvW8NNUN_61Xg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 14, 2015 at 5:57 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rahila Syed 2015-07-15 20:18:44 Re: [PROPOSAL] VACUUM Progress Checker.
Previous Message Robert Haas 2015-07-15 19:23:21 Re: Memory Accounting v11