Re: contrib/cache_scan (Re: What's needed for cache-only table scan?)

On Tue, Mar 4, 2014 at 3:07 PM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)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.

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?

I will update you later regarding the performance test results.

Regards,
Hari Babu
Fujitsu Australia