Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 8D550125101 for ; Tue, 15 May 2012 07:58:14 -0300 (ADT) Received: from mail.anarazel.de ([217.115.131.40]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SUFSF-0000sN-OQ for pgsql-performance@postgresql.org; Tue, 15 May 2012 10:58:13 +0000 Received: from andres.at.anarazel.de.authenticated.anarazel.de by mail.anarazel.de (Postfix) with ESMTPA id BC494448003 for ; Tue, 15 May 2012 12:57:56 +0200 (CEST) From: Andres Freund To: pgsql-performance@postgresql.org Subject: Re: Maximum number of sequences that can be created Date: Tue, 15 May 2012 12:57:53 +0200 User-Agent: KMail/1.13.7 (Linux/3.4.0-rc6-andres-00076-gd60b9c1; KDE/4.7.4; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201205151257.54141.andres@anarazel.de> X-Pg-Spam-Score: -2.6 (--) X-Archive-Number: 201205/92 X-Sequence-Number: 46916 On Tuesday, May 15, 2012 08:29:11 AM =D0=92=D1=96=D1=82=D0=B0=D0=BB=D1=96= =D0=B9 =D0=A2=D0=B8=D0=BC=D1=87=D0=B8=D1=88=D0=B8=D0=BD wrote: > 2012/5/13 Robert Klemme >=20 > > On Sun, May 13, 2012 at 10:12 AM, =D0=92=D1=96=D1=82=D0=B0=D0=BB=D1=96= =D0=B9 =D0=A2=D0=B8=D0=BC=D1=87=D0=B8=D1=88=D0=B8=D0=BD > >=20 > > wrote: > > > 2012/5/11 Robert Klemme > > >=20 > > >> On the contrary: what would be the /advantage/ of being able to crea= te > > >> millions of sequences? What's the use case? > > >=20 > > > We are using sequences as statistics counters - they produce almost no > > > performance impact and we can tolerate it's non-transactional nature.= I > >=20 > > can > >=20 > > > imaging someone who wants to have a sequence per user or other > > > relation row. > >=20 > > I can almost see the point. But my natural choice in that case would > > be a table with two columns. Would that actually be so much less > > efficient? Of course you'd have fully transactional behavior and thus > > locking. >=20 > We've had concurrency problems with table solution (a counter that is > updated by many concurrent queries), so we traded transactionality for > speed. We are actually using this data to graph pretty graphs in nagios, = so > it's quite OK. But we have only ~10 sequences, not millions :) I would rather suggest going with a suming table if you need to do somethin= g=20 like that: sequence_id | value 1 | 3434334 1 | 1 1 | -1 1 | 1 1 | 1 =2E.. You then can get the current value with SELECT SUM(value) WHERE sequence_id= =3D=20 1. For garbage collection you can delete those values and insert the newly= =20 summed up value again. That solution won't ever block if done right. Andres