From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | "Luke Lonergan" <llonergan(at)greenplum(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Jan Wieck" <JanWieck(at)Yahoo(dot)com>, "Chris Browne" <cbbrowne(at)acm(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: TOASTing smaller things |
Date: | 2007-04-12 21:18:44 |
Message-ID: | 5671.1176412724@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> I would suggest that *all* of those TODOs are premature in the absence
>> of experimental evidence about the effect of varying the parameters.
> Isn't it obvious that the "right" value is going to depend extraordinarily
> heavily on the precise usage pattern though?
It's not yet "obvious" that there's any win to be had at all. AFAIK no
one has done any playing around with alternative TOAST settings. It
could be that the mechanism is simply not very sensitive to those values.
> Or perhaps TOAST is the wrong kind of vertical partitioning for this.
Exactly my point --- quoting anecdotes about wins from someone else's
vertical partitioning implementation doesn't really prove a darn thing
about how TOAST will behave. It's suggestive, but I'd like to see some
actual experimental evidence before we start constructing a lot of
infrastructure. "Infrastructure first, learn how to use it later" is
the philosophy that's given us nigh-useless stuff like commit_delay.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-04-12 21:24:52 | Re: Strangely Variable Query Performance |
Previous Message | Gregory Stark | 2007-04-12 21:12:49 | Re: TOASTing smaller things |