2014-03-06 18:17 GMT+09:00 Haribabu Kommi <kommi.harib...@gmail.com>: > > On Tue, Mar 4, 2014 at 3:07 PM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote: >> >> > > 4. + cchunk = ccache_vacuum_tuple(ccache, ccache->root_chunk, &ctid); >> > > + if (pchunk != NULL && pchunk != cchunk) >> > > >> > > + ccache_merge_chunk(ccache, pchunk); >> > > >> > > + pchunk = cchunk; >> > > >> > > >> > > The merge_chunk is called only when the heap tuples are spread >> > > across two cache chunks. Actually one cache chunk can accommodate one >> > > or more than heap pages. it needs some other way of handling. >> > > >> > I adjusted the logic to merge the chunks as follows: >> > >> > Once a tuple is vacuumed from a chunk, it also checks whether it can be >> > merged with its child leafs. A chunk has up to two child leafs; left one >> > has less ctid that the parent, and right one has greater ctid. It means >> > a chunk without right child in the left sub-tree or a chunk without left >> > child in the right sub-tree are neighbor of the chunk being vacuumed. In >> > addition, if vacuumed chunk does not have either (or both) of children, >> > it can be merged with parent node. >> > I modified ccache_vacuum_tuple() to merge chunks during t-tree >> > walk-down, >> > if vacuumed chunk has enough free space. >> > > > > Patch looks good. > Thanks for your volunteering.
> Regarding merging of the nodes, instead of checking whether merge is > possible or not for every tuple which is vacuumed, > can we put some kind of threshold as whenever the node is 50% free then try > to merge it from leaf nodes until 90% is full. > The rest of the 10% will be left for the next inserts on the node. what do > you say? > Hmm. Indeed, it makes sense. How about an idea that kicks chunk merging if "expected" free space of merged chunk is less than 50%? If threshold depends on the (expected) usage of merged chunk, it can avoid over-merging. > I will update you later regarding the performance test results. > Thhanks, Also, I'll rebase the patch on top of the new custom-scan interfaces according to Tom's suggestion, even though main logic of cache_scan is not changed. Best regards, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
