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

Re: Significantly larger toast tables on 8.4?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Stephen R(dot) van den Berg" <srb(at)cuci(dot)nl>, Alex Hunsaker <badalex(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Significantly larger toast tables on 8.4?
Date: 2009-01-03 01:46:21
Message-ID: 15154.1230947181@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> I think the right value for this setting is going to depend on the
> environment. If the system is starved for cpu cycles then you won't want to
> compress large data. If it's starved for i/o bandwidth but has spare cpu
> cycles then you will.

> If that's true then we really have to expose this parameter to users. There
> won't be a single value that is appropriate for everyone.

Yeah.  The commit message for these changes commented

	There was some discussion in the earlier threads of exposing some
	of the compression knobs to users, perhaps even on a per-column
	basis.  I have not done anything about that here.  It seems to me
	that if we are changing around the parameters, we'd better get some
	experience and be sure we are happy with the design before we set
	things in stone by providing user-visible knobs.

and I'm still pretty worried about the longevity of any knob we put in
here.  But we might not have a lot of choice.

It would be fairly easy, I think, to add some reloption fields that
would let these parameters be controlled on a per-table level.
Per-column would be much more painful; do we really need that?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Alex HunsakerDate: 2009-01-03 02:27:46
Subject: Re: Significantly larger toast tables on 8.4?
Previous:From: Joe ConwayDate: 2009-01-03 01:43:42
Subject: Re: BUG #4599: bugfix for contrib/dblink module

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