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

From Haribabu Kommi
Subject Re: contrib/cache_scan (Re: What's needed for cache-only table scan?)
Date
Msg-id CAJrrPGdBUh2KyCRC+Ve=_rv5bCQyGtw4Fex_LkKoo2M0DO8VjQ@mail.gmail.com
Whole thread Raw
In response to Re: contrib/cache_scan (Re: What's needed for cache-only table scan?)  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: contrib/cache_scan (Re: What's needed for cache-only table scan?)  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: narwhal and PGDLLIMPORT
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Making strxfrm() blobs in indexes work