From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Glaesemann <grzm(at)myrealbox(dot)com> |
Cc: | A Gilmore <agilmore(at)shaw(dot)ca>, pgsql-novice(at)postgresql(dot)org |
Subject: | Re: timestamp precision |
Date: | 2004-09-13 14:28:52 |
Message-ID: | 9563.1095085732@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Michael Glaesemann <grzm(at)myrealbox(dot)com> writes:
> On Sep 13, 2004, at 4:19 PM, A Gilmore wrote:
>> Im using the default precision for my timestamps, 6. Is it safe to
>> declare this column unique?
> If you are assuming it's unique because of the high precision, well,
> you might get lucky, and you might not. (Some might even argue that
> it's for all intents and purposes unique).
I think what he's wondering is whether every two transactions will get
distinguishable values of now(), so that putting a UNIQUE constraint on
timestamps inserted by distinct transactions could never fail.
I think this is an unsafe assumption, because:
1. The amount of precision that is actually in the now() value is
unspecified, and varies depending on the hardware and OS. On older
machines it's quite possible that now() only advances once per clock
tick interrupt (60 or 100 times per second).
2. Even if the now() quantum is less than the minimum time to complete
a transaction, what if two clients launch transactions concurrently?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-09-13 14:47:55 | Re: LockAcquire: lock table 1 is out of memory |
Previous Message | Devrim GUNDUZ | 2004-09-13 13:43:38 | Re: create table error |