From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Zeugswetter Andreas ADI SD <ZeugswetterA(at)spardat(dot)at> |
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 14:41:23 |
Message-ID: | 200706061441.l56EfNo26684@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Zeugswetter Andreas ADI SD wrote:
>
> > > 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
Right.
> 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.
Well, it is summarized here:
http://momjian.us/expire/TOAST/SUMMARY.html
It made non-TOAST access 2x faster, but TOAST 7x slower, and that seemed
like a good compromise.
> 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.
That is certainly not my intent, and I don't see how you would get the
2k number from that macro. I think you are looking at 8.2 and not CVS
HEAD. CVS HEAD has:
#define TOAST_TUPLE_TARGET TOAST_TUPLE_THRESHOLD
> 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.
None of this spliting is going to happen for 8.3. The question what
changes we can make for 8.3, if any.
--
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. +
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-06-06 15:03:25 | Re: Controlling Load Distributed Checkpoints |
Previous Message | Alvaro Herrera | 2007-06-06 14:36:59 | Re: Implicit casts with generic arrays |