Re: Vertical Partitioning with TOAST

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Junji TERAMOTO <teramoto(dot)junji(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org, Jan Wieck <JanWieck(at)Yahoo(dot)com>
Subject: Re: Vertical Partitioning with TOAST
Date: 2005-12-08 15:03:43
Message-ID: 200512081503.jB8F3hc09241@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim C. Nasby wrote:
> On Thu, Dec 08, 2005 at 12:59:47AM -0500, Tom Lane wrote:
> > "Jim C. Nasby" <jim(at)nasby(dot)net> writes:
> > > This seems like a useful feature to add, allowing for easy built-in
> > > verticle partitioning. Are there issues with the patch as-is?
> >
> > Other than the ones mentioned by the poster?
> >
> > It seemed to me more like a not-too-successful experiment than something
> > ready for application. If you take the viewpoint that this is just
> > another TOAST storage strategy, I think it's pretty useless. A large
> > field value is going to get toasted anyway with the regular strategy,
> > and if your column happens to contain some values that are not large,
> > forcing them out-of-line anyway is simply silly. (You could make a case
> > for making the threshold size user-controllable, but I don't see the
> > case for setting the threshold to zero, which is what this amounts to.)
>
> Valid point. I do think there's a lot of benefit to being able to set
> the limit much lower than what it currently defaults to today. We have a
> client that has a queue-type table that is updated very frequently. One
> of the fields is text, that is not updated as frequently. Keeping this
> table vacuumed well enough has proven to be problematic, because any
> delay to vacuuming quickly results in a very large amount of bloat.
> Moving that text field into a seperate table would most likely be a win.
>
> Presumably this would need to be settable on at least a per-table basis.
>
> Would adding such a variable be a good beginner TODO, or is it too
> invasive?

Well, we have now:

ALTER TABLE ALTER [ COLUMN ] column
SET STORAGE { PLAIN | EXTERNAL | EXTENDED | MAIN }

What else is needed?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-12-08 15:05:15 Re: Reducing relation locking overhead
Previous Message Tom Lane 2005-12-08 14:50:53 Re: forced to restart postgresql service yesterday