Re: contrib/cache_scan (Re: What's needed for cache-only table scan?)
От | Kouhei Kaigai |
---|---|
Тема | Re: contrib/cache_scan (Re: What's needed for cache-only table scan?) |
Дата | |
Msg-id | 9A28C8860F777E439AA12E8AEA7694F8F8BAC0@BPXM15GP.gisp.nec.co.jp обсуждение исходный текст |
Ответ на | Re: contrib/cache_scan (Re: What's needed for cache-only table scan?) (Haribabu Kommi <kommi.haribabu@gmail.com>) |
Список | pgsql-hackers |
> > Also, I split the patches again because *demonstration* part is much > > larger than the patches to the core backend. It will help reviewing. > > * pgsql-v9.4-vacuum_page_hook.v11.patch > > -> It adds a hook for each page being vacuumed; that needs to synchronize > > the status of in-memory cache managed by extension. > > * pgsql-v9.4-mvcc_allows_cache.v11.patch > > -> It allows to run HeapTupleSatisfiesVisibility() towards the tuples > > on the in-memory cache, not on the heap. > > * pgsql-v9.4-example-cache_scan.v11.patch > > -> It demonstrates the usage of above two patches. It allows to scan > > a relation without storage access if possible. > > All the patches are good. The cache scan extension patch may need further > refinement in terms of performance improvement but the same can be handled > later also. > So I am marking the patch as "ready for committer". Thanks for the patch. > Thanks for your dedicated efforts on these patches. The smaller portions of above submission can be applied independent from the custom-plan interface, and its scale is much smaller than contrib/ portion (about 30lines in total). If someone can pick them up individually from the extension portion, it also makes sense. I intended to implement the extension portion as simple as I can, for the demonstration purpose rather than performance, however, its scale is about 2.5KL. :-( Yes, I know the time pressure towards v9.4 final feature freeze.... Best regards, -- 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: Tuesday, March 18, 2014 11:14 AM > To: Kaigai Kouhei(海外 浩平) > Cc: Kohei KaiGai; Tom Lane; PgHacker; Robert Haas > Subject: Re: contrib/cache_scan (Re: [HACKERS] What's needed for cache-only > table scan?) > > On Mon, Mar 17, 2014 at 11:45 AM, Kouhei Kaigai <kaigai@ak.jp.nec.com> > wrote: > > Hello, > > > > The attached patches are revised ones according to the latest > > custom-plan interface patch (v11). > > The cache-scan module was re-implemented on the newer interface, and > > also I noticed the extension does not handle the tuples being > > redirected correctly, So, I revised the logic in ccache_vacuum_page() > > totally. It now becomes to synchronize the cached tuples per page, not > > per tuple, basic and tries to merge t-tree chunks per page basis also. > > > > Also, I split the patches again because *demonstration* part is much > > larger than the patches to the core backend. It will help reviewing. > > * pgsql-v9.4-vacuum_page_hook.v11.patch > > -> It adds a hook for each page being vacuumed; that needs to synchronize > > the status of in-memory cache managed by extension. > > * pgsql-v9.4-mvcc_allows_cache.v11.patch > > -> It allows to run HeapTupleSatisfiesVisibility() towards the tuples > > on the in-memory cache, not on the heap. > > * pgsql-v9.4-example-cache_scan.v11.patch > > -> It demonstrates the usage of above two patches. It allows to scan > > a relation without storage access if possible. > > All the patches are good. The cache scan extension patch may need further > refinement in terms of performance improvement but the same can be handled > later also. > So I am marking the patch as "ready for committer". Thanks for the patch. > > Regards, > Hari Babu > Fujitsu Australia
В списке pgsql-hackers по дате отправления: