> > 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. Thanks, -- NEC OSS Promotion Center / PG-Strom Project KaiGai Kohei <kai...@ak.jp.nec.com> > -----Original Message----- > From: Haribabu Kommi [mailto:kommi.harib...@gmail.com] > Sent: Thursday, February 13, 2014 8:31 AM > To: Kohei KaiGai > Cc: Kaigai, Kouhei(海外, 浩平); Tom Lane; PgHacker; Robert Haas > Subject: Re: contrib/cache_scan (Re: [HACKERS] What's needed for cache-only > table scan?) > > On Thu, Feb 13, 2014 at 2:42 AM, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: > > > 2014-02-12 14:59 GMT+09:00 Haribabu Kommi > <kommi.harib...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
