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

On Thu, Feb 13, 2014 at 2:42 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:

> 2014-02-12 14:59 GMT+09:00 Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>:
> > 7. In ccache_find_tuple function this Assert(i_min + 1 < cchunk->ntups);
> can
> > go wrong when only one tuple present in the block
> > with the equal item pointer what we are searching in the forward scan
> > direction.
> >
> It shouldn't happen, because the first or second ItemPointerCompare will
> handle the condition. Please assume the cchunk->ntups == 1. In this case,
> any given ctid shall match either of them, because any ctid is less, equal
> or
> larger to the tuple being only cached, thus, it moves to the right or left
> node
> according to the scan direction.

yes you are correct. sorry for the noise.

> > 8. I am not able to find a protection mechanism in insert/delete and
> etc of
> > a tuple in Ttree. As this is a shared memory it can cause problems.
> >
> For design simplification, I put a giant lock per columnar-cache.
> So, routines in cscan.c acquires exclusive lwlock prior to invocation of
> ccache_insert_tuple / ccache_delete_tuple.

Correct. But this lock can be a bottleneck for the concurrency. Better to
analyze the same once we have the performance report.

Regards,
Hari Babu
Fujitsu Australia