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

Поиск
Список
Период
Сортировка
От Haribabu Kommi
Тема Re: contrib/cache_scan (Re: What's needed for cache-only table scan?)
Дата
Msg-id CAJrrPGdBUh2KyCRC+Ve=_rv5bCQyGtw4Fex_LkKoo2M0DO8VjQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: contrib/cache_scan (Re: What's needed for cache-only table scan?)  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Ответы Re: contrib/cache_scan (Re: What's needed for cache-only table scan?)  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
Список 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 по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: narwhal and PGDLLIMPORT
Следующее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Making strxfrm() blobs in indexes work