Re: Vertical Partitioning with TOAST

Hello all,

Thank you for having the interest.

Jim C. Nasby wrote:
> 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.

Yes, our team think that this patch is effective that the tuple can be
partially updated.
For instance, DBT-2 updates frequently contents excluding c_data in the
customer table. Because c_data(about 400bytes: The size of the entire
tuple is 500bytes.) is copied together in every case, it is thought that
it has decreased the performance.
That is more important than the vertical partitioning function.

Of course, it is important to change DDL of the table. However, I think
it might be useful when it is not possible to change.

As pointed out by Tom, this is a patch to verify the idea.
I want to know that community is how much interested in a partial update.
Of course, it is interested whether to want the vertical partitioning
function in PostgreSQL, too. :-)


By the way, should I send the patch to -patches again?

-- 
Junji Teramoto / teramoto.junji (a) lab.ntt.co.jp