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

> > 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(at)ak(dot)jp(dot)nec(dot)com>

> -----Original Message-----
> From: Haribabu Kommi [mailto:kommi(dot)haribabu(at)gmail(dot)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(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