Skip site navigation (1) Skip section navigation (2)

Re: TOAST usage setting

From: "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at>
To: "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>,"Gregory Stark" <stark(at)enterprisedb(dot)com>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TOAST usage setting
Date: 2007-06-06 08:43:18
Message-ID: E1539E0ED7043848906A8FF995BDA579021B32AF@m0143.s-mxs.net (view raw or flat)
Thread:
Lists: pgsql-hackers
> > No, you misunderstood. Bruce was suggesting changing the target to
512.
> > That means if a row is wider than ~2k, toaster will try to toast
until 
> > the base row is
> > ~512 bytes. I would not do that part for 8.3. 
> 
> OK, what do you suggest for 8.3?  Attached are my suggestion 
> to use 512 and a 4k chunk size, which I think means that 2.7k 
> is the worst values that has a loss of around 25%.

Oh, so I misunderstood you also. You are suggesting two changes:
TOAST_TUPLES_PER_PAGE	16
EXTERN_TUPLES_PER_PAGE	2

While I agree, that 2 might be a good compromise with low risc for now,
I think
that toasting all rows down to ~512 bytes is too narrowly targeted at
not reading wider columns.

When suggesting a new target, I interpreted you like so:
#define TOAST_TUPLES_PER_PAGE	4
#define TOAST_TUPLE_TARGET	\
	MAXALIGN_DOWN((BLCKSZ - \
				   MAXALIGN(sizeof(PageHeaderData) +
(TOAST_TUPLES_PER_PAGE-1) * sizeof(ItemIdData))) \
				  / 16)
So we would only toast rows wider than 2k, but once toasting, toast the
base row down to 512.  

My suggestion would be to leave TOAST_TUPLES_PER_PAGE as is, because all
else would need extensive performance testing.
#define TOAST_TUPLES_PER_PAGE	4

My next suggestion would be to leave EXTERN_TUPLES_PER_PAGE as is, but:
Split data wider than a page into page sized chunks as long as they fill
whole pages.
Split the rest with EXTERN_TUPLES_PER_PAGE (4) as now.
This would not waste more space than currently, but improve performance
for very wide columns.

I can try to do a patch if you think that is a good idea, can't do a lot
of testing though.

Andreas

In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2007-06-06 13:19:12
Subject: Controlling Load Distributed Checkpoints
Previous:From: Pavel StehuleDate: 2007-06-06 08:17:28
Subject: Re: Implicit casts with generic arrays

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group