Re: patch : Allow toast tables to be moved to a different tablespace - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: patch : Allow toast tables to be moved to a different tablespace
Date
Msg-id CANP8+jJ4xL7URGz-8YDSD+JF1+V0fQYcz6jSW7KXp+T+1ikjKA@mail.gmail.com
Whole thread Raw
In response to Re: patch : Allow toast tables to be moved to a different tablespace  (Andreas Karlsson <andreas@proxel.se>)
List pgsql-hackers
On 3 August 2015 at 01:35, Andreas Karlsson <andreas@proxel.se> wrote:
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.

To me the patch looks like it is in reasonable shape, caveats noted.

The patch doesn't really take us very far forwards in terms of administration since workarounds exist which people use and understand. Noting Tom's comments on additional complexity it seems like it could be a source of bugs or production problems. 

The deciding factor is that it brings TOAST as a keyword for us to support forever. While reviewing this, I've come to realise that a better approach to column stores and/or vertical partitioning is the more general way of handling this, so creating a support legacy at this time doesn't make sense to me personally.

On balance, the negatives seem to outweigh the positives so isn't the best use of my time to fix it up.

I'm now returning this with feedback.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Raising our compiler requirements for 9.6
Next
From: Andres Freund
Date:
Subject: Re: Macro nesting hell