Re: TOASTing smaller things

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Luke Lonergan <llonergan(at)greenplum(dot)com>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: TOASTing smaller things
Date: 2007-03-27 00:39:54
Message-ID: 200703270039.l2R0dsN11777@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Luke Lonergan wrote:
> I advocate the following:
>
> - Enable specification of TOAST policy on a per column basis
>
> As a first step, then:
>
> - Enable vertical partitioning of tables using per-column specification of
> storage policy.
>

How are these different from ALTER TABLE SET STORAGE? They need to be
more specific.

---------------------------------------------------------------------------

> - Luke
>
>
> On 3/21/07 1:12 PM, "Bruce Momjian" <bruce(at)momjian(dot)us> wrote:
>
> >
> > Is this a TODO?
> >
> > ---------------------------------------------------------------------------
> >
> > Jan Wieck wrote:
> >> On 3/21/2007 2:05 PM, Tom Lane wrote:
> >>> Chris Browne <cbbrowne(at)acm(dot)org> writes:
> >>>> #define TOAST_DENOMINATOR 17
> >>>> /* Use this as the divisor; current default behaviour falls from
> >>>> TOAST_DENOMINATOR = 4 */
> >>>
> >>>> #define TOAST_TUPLE_THRESHOLD^I\
> >>>> ^IMAXALIGN_DOWN((BLCKSZ - \
> >>>> ^I^I^I^I MAXALIGN(sizeof(PageHeaderData) + 3 * sizeof(ItemIdData))) \
> >>>> ^I^I^I^I / TOAST_DENOMINATOR)
> >>>
> >>> Given that you are quoting code that was demonstrably broken since the
> >>> original coding of TOAST up till a month or two back, "it passes
> >>> regression" is not adequate proof of "it's right". In fact I think
> >>> it's not right; you have not got the roundoff condition straight.
> >>>
> >>>> 4. A different mechanism would be to add a fifth storage column
> >>>> strategy (the present four are PLAIN, EXTENDED, EXTERNAL, MAIN), let's
> >>>> say, TOAST.
> >>
> >> FORCE_COMPRESSION, FORCE_EXTERNAL and FORCE_EXTERNAL_UNCOMPRESSED.
> >>
> >>>
> >>> Anything along this line would require invoking the toaster on every
> >>> single tuple, since we'd always have to crawl through all the columns
> >>> to see if toasting was supposed to happen. No thanks.
> >>
> >> Not necessarily. A flag in Relation telling if the table has any column
> >> marked like that could be set while constructing the relcache entry.
> >>
> >>>
> >>>> Which of these sounds preferable?
> >>>
> >>> It's a bit late in the cycle to be proposing any of these for 8.3.
> >>
> >> Certainly.
> >>
> >>
> >> Jan
> >>
> >> --
> >> #======================================================================#
> >> # It's easier to get forgiveness for being wrong than for being right. #
> >> # Let's break this rule - forgive me. #
> >> #================================================== JanWieck(at)Yahoo(dot)com #
> >>
> >> ---------------------------(end of broadcast)---------------------------
> >> TIP 2: Don't 'kill -9' the postmaster

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2007-03-27 00:52:47 Re: patch adding new regexp functions
Previous Message Bruce Momjian 2007-03-27 00:37:43 Re: Patch for pg_dump