pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Andres Freund <andres@anarazel.de>
To: pgsql-performance@postgresql.org
Subject: Re: Maximum number of sequences that can be created
Date: Tue, 15 May 2012 12:57:53 +0200
Message-ID: <201205151257.54141.andres@anarazel.de> (raw)
In-Reply-To: <CABWW-d0DCTDG9o6gA95e5CrLhrHLf=ynHAccGMFeW15gioVreA@mail.gmail.com>
References: <CA+_YOSf+WykZQg2EEpY_h6k1kr62bzPvmgv=YB0CTh74JZGJbA@mail.gmail.com>
	<CAM9pMnOCKEEKbvhtLoTym9cY9xspr3S12V6bWbcsQxtHsyzMGw@mail.gmail.com>
	<CABWW-d0DCTDG9o6gA95e5CrLhrHLf=ynHAccGMFeW15gioVreA@mail.gmail.com>

On Tuesday, May 15, 2012 08:29:11 AM Віталій Тимчишин wrote:
> 2012/5/13 Robert Klemme <shortcutter@googlemail.com>
> 
> > On Sun, May 13, 2012 at 10:12 AM, Віталій Тимчишин <tivv00@gmail.com>
> > 
> > wrote:
> > > 2012/5/11 Robert Klemme <shortcutter@googlemail.com>
> > > 
> > >> On the contrary: what would be the /advantage/ of being able to create
> > >> millions of sequences?  What's the use case?
> > > 
> > > We are using sequences as statistics counters - they produce almost no
> > > performance impact and we can tolerate it's non-transactional nature. I
> > 
> > can
> > 
> > > imaging someone who wants to have a  sequence per user or other
> > > relation row.
> > 
> > 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.
> 
> 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 something 
like that:

sequence_id | value
1 | 3434334
1 | 1
1 | -1
1 | 1
1 | 1
...

You then can get the current value with SELECT SUM(value) WHERE sequence_id = 
1. For garbage collection you can delete those values and insert the newly 
summed up value again.
That solution won't ever block if done right.

Andres



view thread (11+ messages)  latest in thread

Message-ID: <201205151257.54141.andres@anarazel.de>
Permalink:  ../201205151257.54141.andres@anarazel.de/
Also on:    postgresql.org/message-id/201205151257.54141.andres@anarazel.de

 · 

reply

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-performance@postgresql.org
  Cc: andres@anarazel.de
  Subject: Re: Maximum number of sequences that can be created
  In-Reply-To: <201205151257.54141.andres@anarazel.de>

* 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