From: | Віталій Тимчишин <tivv00(at)gmail(dot)com> |
---|---|
To: | Robert Klemme <shortcutter(at)googlemail(dot)com> |
Cc: | pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Maximum number of sequences that can be created |
Date: | 2012-05-15 06:29:11 |
Message-ID: | CABWW-d0DCTDG9o6gA95e5CrLhrHLf=ynHAccGMFeW15gioVreA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
2012/5/13 Robert Klemme <shortcutter(at)googlemail(dot)com>
> On Sun, May 13, 2012 at 10:12 AM, Віталій Тимчишин <tivv00(at)gmail(dot)com>
> wrote:
> > 2012/5/11 Robert Klemme <shortcutter(at)googlemail(dot)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 :)
--
Best regards,
Vitalii Tymchyshyn
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-05-15 10:57:53 | Re: Maximum number of sequences that can be created |
Previous Message | Jeff Janes | 2012-05-14 22:50:05 | Re: Maximum number of sequences that can be created |