On Thu, Dec 08, 2005 at 12:59:47AM -0500, Tom Lane wrote:
> "Jim C. Nasby" <jim@nasby.net> writes:
> > This seems like a useful feature to add, allowing for easy built-in
> > verticle partitioning. Are there issues with the patch as-is?
>
> Other than the ones mentioned by the poster?
>
> It seemed to me more like a not-too-successful experiment than something
> ready for application. If you take the viewpoint that this is just
> another TOAST storage strategy, I think it's pretty useless. A large
> field value is going to get toasted anyway with the regular strategy,
> and if your column happens to contain some values that are not large,
> forcing them out-of-line anyway is simply silly. (You could make a case
> for making the threshold size user-controllable, but I don't see the
> case for setting the threshold to zero, which is what this amounts to.)
Valid point. I do think there's a lot of benefit to being able to set
the limit much lower than what it currently defaults to today. We have a
client that has a queue-type table that is updated very frequently. One
of the fields is text, that is not updated as frequently. Keeping this
table vacuumed well enough has proven to be problematic, because any
delay to vacuuming quickly results in a very large amount of bloat.
Moving that text field into a seperate table would most likely be a win.
Presumably this would need to be settable on at least a per-table basis.
Would adding such a variable be a good beginner TODO, or is it too
invasive?
> Personally, I'd rather look into whether we couldn't speed up TOAST
> without changing any of its basic assumptions. The current
> implementation isn't awful, but it was built to allow the existing table
> and index mechanisms to be re-used for TOAST data. Now that we know for
> certain TOAST is a good idea, it would be reasonable to take a second
> look at whether we could improve the performance with another round of
> implementation effort.
I've often wondered about all the overhead of storing toast data in what
amounts to a regular table. Sounds like another TODO...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461