Re: Significantly larger toast tables on 8.4? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Significantly larger toast tables on 8.4?
Date
Msg-id 15154.1230947181@sss.pgh.pa.us
Whole thread Raw
In response to Re: Significantly larger toast tables on 8.4?  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: Significantly larger toast tables on 8.4?  ("Alex Hunsaker" <badalex@gmail.com>)
Re: Significantly larger toast tables on 8.4?  ("Stephen R. van den Berg" <srb@cuci.nl>)
Re: Significantly larger toast tables on 8.4?  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
Gregory Stark <stark@enterprisedb.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 someof the compression knobs to users, perhaps even on a
per-columnbasis. I have not done anything about that here.  It seems to methat if we are changing around the
parameters,we'd better get someexperience and be sure we are happy with the design before we setthings in stone by
providinguser-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


pgsql-hackers by date:

Previous
From: "Robert Haas"
Date:
Subject: Re: posix_fadvise v22
Next
From: "Alex Hunsaker"
Date:
Subject: Re: Significantly larger toast tables on 8.4?