| From: | Markus Wanner <markus(at)bluegap(dot)ch> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Jim Nasby <jim(at)nasby(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: cheaper snapshots redux |
| Date: | 2011-08-25 05:55:37 |
| Message-ID: | 4E55E3D9.1020808@bluegap.ch |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert,
On 08/25/2011 04:59 AM, Robert Haas wrote:
> True; although there are some other complications. With a
> sufficiently sophisticated allocator you can avoid mutex contention
> when allocating chunks, but then you have to store a pointer to the
> chunk somewhere or other, and that then requires some kind of
> synchronization.
Hm.. right.
> One difference with snapshots is that only the latest snapshot is of
> any interest.
Theoretically, yes. But as far as I understood, you proposed the
backends copy that snapshot to local memory. And copying takes some
amount of time, possibly being interrupted by other backends which add
newer snapshots... Or do you envision the copying to restart whenever a
new snapshot arrives?
Regards
Markus
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dean Rasheed | 2011-08-25 09:39:09 | Inputting relative datetimes |
| Previous Message | Robert Haas | 2011-08-25 02:59:14 | Re: cheaper snapshots redux |