Skip site navigation (1) Skip section navigation (2)

Re: pg_last_xact_insert_timestamp

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(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-08 13:03:14
Message-ID: CA+TgmoZMeb0w9g0oCP88MGvdVFaO+gqRsxrA=szChrvzQwgsBQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Sep 8, 2011 at 6:14 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> OTOH, new function enables users to monitor the delay as a timestamp.
> For users, a timestamp is obviously easier to handle than LSN, and the delay
> as a timestamp is more intuitive. So, I think that it's worth adding
> something like pg_last_xact_insert_timestamp into core for improvement
> of user-friendness.

It seems very nice from a usability point of view, but I have to agree
with Simon's concern about performance.  Actually, as of today,
WALInsertLock is such a gigantic bottleneck that I suspect the
overhead of this additional bookkeeping would be completely
unnoticeable.  But I'm still reluctant to add more centralized
spinlocks that everyone has to fight over, having recently put a lot
of effort into getting rid of some of the ones we've traditionally
had.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Aidan Van DykDate: 2011-09-08 13:09:37
Subject: Re: postgresql.conf archive_command example
Previous:From: Marti RaudseppDate: 2011-09-08 12:59:57
Subject: Re: [PATCH] Don't truncate integer part in to_char for 'FM99.'

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group