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

On Thu, Feb 13, 2014 at 3:27 PM, Kouhei Kaigai wrote:

> > > 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.
> >
> Well, concurrent updates towards a particular table may cause lock
> contention
> due to a giant lock.
> On the other hands, one my headache is how to avoid dead-locking if we try
> to
> implement it using finer granularity locking. Please assume per-chunk
> locking.
> It also needs to take a lock on the neighbor nodes when a record is moved
> out.
> Concurrently, some other process may try to move another record with
> inverse
> order. That is a ticket for dead-locking.
>
> Is there idea or reference to implement concurrent tree structure updating?
>
> Anyway, it is a good idea to measure the impact of concurrent updates on
> cached tables, to find out the significance of lock splitting.

we can do some of the following things,
1. Let only insert can take the exclusive lock.
2. Always follow the locking order from root to the children.
3. For delete take exclusive lock only on the exact node where the delete
is happening.
and etc, we will identify some more based on the performance data.

And one more interesting document i found in the net while searching for
the concurrency in Ttree,
which says that B-tree can outperform Ttree as an in-memory index also with
an little bit expensive of more memory
usage. The document is attached in the mail.

Regards,
Hari Babu
Fujitsu Australia