| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Cc: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, 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 06:21:08 |
| Message-ID: | 24280.1412403668@sss.pgh.pa.us |
| 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.
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2014-10-04 06:35:37 | Re: [RFC] Incremental backup v2: add backup profile to base backup |
| Previous Message | Michael Paquier | 2014-10-04 06:01:03 | Re: pg_receivexlog and replication slots |