Re: How to make ResourceOwnerForgetBuffer() O(1), instead of O(N^2) scale

Поиск
Список
Период
Сортировка
От Kouhei Kaigai
Тема Re: How to make ResourceOwnerForgetBuffer() O(1), instead of O(N^2) scale
Дата
Msg-id 9A28C8860F777E439AA12E8AEA7694F8010481FF@BPXM15GP.gisp.nec.co.jp
обсуждение исходный текст
Ответ на Re: How to make ResourceOwnerForgetBuffer() O(1), instead of O(N^2) scale  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> > On 10/03/2014 07:08 AM, Kouhei Kaigai wrote:
> >> What is the best way to solve the problem?
>
> > How about creating a separate ResourceOwner for these buffer pins, and
> > doing a wholesale ResourceOwnerRelease() on it when you're done?
>
> That's a thought.  Another point is that if you can release the buffer pins
> in reverse order of acquisition, the existing ResourceOwner code works just
> fine.
>
Yep, I'm now trying.

> I have a larger question though: how is it useful to transfer raw contents
> of shared buffers to a GPU in the first place?
> Surely you're not going to be putting tasks like tuple visibility
> verification into the GPU.  So it seems like this whole thread is based
> on a dubious architectural assumption.
>
In my implementation, it is a job of GPU to check tuple visibility, then
it also send GPU an array of visible item index, in addition to the buffer
contents itself. GPU code can pick up only visible tuples using this index.
OLAP workloads tends to have all-visible pages, so cost of visibility check
was not expensive.

Thanks,
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kouhei Kaigai
Дата:
Сообщение: Re: How to make ResourceOwnerForgetBuffer() O(1), instead of O(N^2) scale
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Fixed xloginsert_locks for 9.4