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
