Re: How to make ResourceOwnerForgetBuffer() O(1), instead of O(N^2) scale - Mailing list pgsql-hackers

From Kouhei Kaigai
Subject Re: How to make ResourceOwnerForgetBuffer() O(1), instead of O(N^2) scale
Date
Msg-id 9A28C8860F777E439AA12E8AEA7694F8010481FF@BPXM15GP.gisp.nec.co.jp
Whole thread Raw
In response to Re: How to make ResourceOwnerForgetBuffer() O(1), instead of O(N^2) scale  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Kouhei Kaigai
Date:
Subject: Re: How to make ResourceOwnerForgetBuffer() O(1), instead of O(N^2) scale
Next
From: Bruce Momjian
Date:
Subject: Re: Fixed xloginsert_locks for 9.4