From: Tom Lane <tgl@sss.pgh.pa.us>
To: Oliver Elphick <olly@lfix.co.uk>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Andrew Sullivan <andrew@libertyrms.info>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [SQL] [GENERAL] CURRENT_TIMESTAMP
Date: Fri, 04 Oct 2002 01:20:55 -0400
Message-ID: <17731.1033708855@sss.pgh.pa.us> (raw)
In-Reply-To: <1033707793.722.963.camel@linda>
References: <200210040041.g940fx615950@candle.pha.pa.us>
<1033707793.722.963.camel@linda>
Oliver Elphick <olly@lfix.co.uk> writes:
> I can see that the current behaviour might give surprising results in a
> long running transaction. Surprise could be reduced by giving the time
> of first use within the transaction rather than the start of the
> transaction.
[ cogitates ... ] Hmm, we could do that, and it probably would break
few if any existing apps. But would it really reduce the surprise
factor? The complaints we've heard so far all seemed to come from
people who expected multiple current_timestamp calls to show advancing
times within a transaction.
Oliver's idea might be worth doing just on performance grounds: instead
of a gettimeofday() call at the start of every transaction, we'd only
have to reset a flag variable. When and if current_timestamp is done
inside the transaction, then call the kernel to ask what time it is.
We win on every transaction that does not contain a current_timestamp
call, which is probably a good bet for most apps. But I don't think
this does much to resolve the behavioral complaints.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: tgl@sss.pgh.pa.us, olly@lfix.co.uk, pgman@candle.pha.pa.us, andrew@libertyrms.info, pgsql-hackers@postgresql.org
Subject: Re: [SQL] [GENERAL] CURRENT_TIMESTAMP
In-Reply-To: <17731.1033708855@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox