Re: Vertical Partitioning with TOAST - Mailing list pgsql-hackers

From Junji TERAMOTO
Subject Re: Vertical Partitioning with TOAST
Date
Msg-id 4397F40B.6000209@lab.ntt.co.jp
Whole thread Raw
In response to Re: Vertical Partitioning with TOAST  ("Jim C. Nasby" <jim@nasby.net>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Vertical Partitioning with TOAST
Next
From: Simon Riggs
Date:
Subject: Re: Reducing relation locking overhead