From: | Oscar Tuscon <obtuse(at)bmwe30(dot)net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Sequence Question DOH! |
Date: | 2004-08-05 20:22:13 |
Message-ID: | 20040805202213.E9E8A725E@sitemail.everyone.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Not sure how I managed to interchange Greg's reply and my response, but here's mine again:
Thanks, I figured that, but was hoping otherwise. I realize that the timing would make it unlikely, but unfortunately I need 100% guaranteed. I have an alternative in that I control the accessing clients (my app) and can apply a lock to prevent it from happening.
I found the average select nextval() call was taking 2ms, which seems a bit slow to me. Throw in the fsync I suppose and that'd explain it.
Interestingly, in the tests I ran the minimum select nextval() was 400us, and the max was 35ms, with an average of 2ms. This was on a DL380 dual 2.4G processors, 2.5G RAM, 5x10k SCSI drives, and no load - pretty much idle (well, a processes checking for entries in a command table 10 times per second).
Oscar
_____________________________________________________________
The BMW E30 community on the web---> http://www.bmwe30.net
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2004-08-05 20:39:01 | Re: trash talk |
Previous Message | ruben | 2004-08-05 20:21:09 | Slow after VACUUM, fast after DROP-CREATE INDEX |