Re: Cache Hash Index meta page.
От | Jesper Pedersen |
---|---|
Тема | Re: Cache Hash Index meta page. |
Дата | |
Msg-id | b0231165-13cc-a6ad-0a45-eaf5f8f22128@redhat.com обсуждение исходный текст |
Ответ на | Cache Hash Index meta page. (Mithun Cy <mithun.cy@enterprisedb.com>) |
Ответы |
Re: Cache Hash Index meta page.
|
Список | pgsql-hackers |
On 07/22/2016 06:02 AM, Mithun Cy wrote: > I have created a patch to cache the meta page of Hash index in > backend-private memory. This is to save reading the meta page buffer every > time when we want to find the bucket page. In “_hash_first” call, we try to > read meta page buffer twice just to make sure bucket is not split after we > found bucket page. With this patch meta page buffer read is not done, if > the bucket is not split after caching the meta page. > > Idea is to cache the Meta page data in rd_amcache and store maxbucket > number in hasho_prevblkno of bucket primary page (which will always be NULL > other wise, so reusing it here for this cause!!!). So when we try to do > hash lookup for bucket page if locally cached maxbucket number is greater > than or equal to bucket page's maxbucket number then we can say given > bucket is not split after we have cached the meta page. Hence avoid reading > meta page buffer. > > I have attached the benchmark results and perf stats (refer > hash_index_perf_stat_and_benchmarking.odc [sheet 1: perf stats; sheet 2: > Benchmark results). There we can see improvements at higher clients, as > lwlock contentions due to buffer read are more at higher clients. If I > apply the same patch on Amit's concurrent hash index patch [1] we can see > improvements at lower clients also. Amit's patch has removed a heavy weight > page lock which was the bottle neck at lower clients. > Could you provide a rebased patch based on Amit's v5 ? Best regards, Jesper
В списке pgsql-hackers по дате отправления: