"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.)
The poster was not actually suggesting applying it in the form of a
force-external TOAST strategy; he was using this as a prototype to try
to interest people in the idea of out-of-line storage mechanisms with
lower overhead than TOAST. But that part is all speculation not code.
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.
regards, tom lane