X-Original-To: pgsql-general-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id C6EF0D1B192 for ; Thu, 5 Aug 2004 16:51:21 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 76627-02 for ; Thu, 5 Aug 2004 19:51:07 +0000 (GMT) Received: from omta06.mta.everyone.net (sitemail3.everyone.net [216.200.145.37]) by svr1.postgresql.org (Postfix) with ESMTP id 5A8DED1B18A for ; Thu, 5 Aug 2004 16:50:57 -0300 (ADT) Received: from sitemail.everyone.net (bigip1-snat [216.200.145.29]) by omta06.mta.everyone.net (Postfix) with ESMTP id BC81F41FDF for ; Thu, 5 Aug 2004 12:50:48 -0700 (PDT) Received: by sitemail.everyone.net (Postfix, from userid 99) id B00977274; Thu, 5 Aug 2004 12:50:48 -0700 (PDT) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Date: Thu, 5 Aug 2004 12:50:48 -0700 (PDT) From: Oscar Tuscon To: pgsql-general@postgresql.org Subject: Re: Sequence Question Reply-To: obtuse@bmwe30.net X-Originating-Ip: [192.94.149.1] X-Eon-Sig: AQHrDFBBEo+YAAp2fAEAAAAB,9e00096191fd91434d7eeb08debb22f2 Message-Id: <20040805195048.B00977274@sitemail.everyone.net> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.1 tagged_above=0.0 required=5.0 tests=GUARANTEED_100_PERCENT X-Spam-Level: * X-Archive-Number: 200408/157 X-Sequence-Number: 63712 >>>> I'm not sure but I don't think that's safe since nextval doesn't lock the sequence until the setval occurs. Though it might be unlikely to actually occur in real life. You could create a table with as many entries as you will ever need and then select nextval() from that table and read all the records you get. That will avoid the many round trips but it will still be slow since you will still have to move all those individual values to your client. Perhaps you should give up on the idea of using sequences at all. If you have a table with one record (or one record per similar application). You could "SELECT n FROM counters FOR UPDATE" the value in the record, then "UPDATE counters SET n = n+?". It would serialize your accesses which would be bad if you had lots of clients doing small increments, but if you have few clients doing large increments it shouldn't be a problem. Do make sure to vacuum this table frequently though. -- greg <<<< 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