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

>     > 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 <kaigai@ak.jp.nec.com>


> -----Original Message-----
> From: Haribabu Kommi [mailto:kommi.haribabu@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 <kaigai@kaigai.gr.jp> wrote:
>
>
>     2014-02-12 14:59 GMT+09:00 Haribabu Kommi
> <kommi.haribabu@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