From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Chris Redekop <chris(at)replicon(dot)com> |
Subject: | Re: pg_last_xact_insert_timestamp |
Date: | 2011-09-11 04:24:10 |
Message-ID: | CAHGQGwEsMSOCmgeOVte5WwHgPTXNr=2aYSDjSQi9f28UBXRT9Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Sep 10, 2011 at 12:32 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Sep 8, 2011 at 8:42 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> Another idea to avoid spinlock contention is save the timestamp in
>> PgBackendStatus (which contains information for pg_stat_activity).
>> This enables us to write and read the timestamp without spinlock.
>> Comments?
>
> That seems like a possibly promising approach, in that each backend
> could update the information separately, and it's the reader's job to
> go find the maximum of all those values when needed. So the overhead
> is (properly, in this case) placed on the reader instead of the
> writer. But it's a bit tricky, because when the reader wants that
> maximum, it has to take into account inactive backends that may have
> committed transactions before exiting, not just the ones that are
> still connected.
Yes, that's what I was thinking. The attached patch has adopted that
approach.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
pg_last_xact_insert_timestamp_v2.patch | application/octet-stream | 13.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2011-09-11 04:56:16 | Re: [REVIEW] prepare plans of embedded sql on function start |
Previous Message | Pavel Stehule | 2011-09-11 04:17:50 | Re: [REVIEW] prepare plans of embedded sql on function start |