From: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | PgHacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: How to make ResourceOwnerForgetBuffer() O(1), instead of O(N^2) scale |
Date: | 2014-10-04 10:10:04 |
Message-ID: | 9A28C8860F777E439AA12E8AEA7694F8010481FF@BPXM15GP.gisp.nec.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Heikki Linnakangas <hlinnakangas(at)vmware(dot)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(at)ak(dot)jp(dot)nec(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2014-10-04 15:07:13 | Re: Fixed xloginsert_locks for 9.4 |
Previous Message | Kouhei Kaigai | 2014-10-04 10:01:04 | Re: How to make ResourceOwnerForgetBuffer() O(1), instead of O(N^2) scale |