Re: Multiple Sequence Number for One Column p.2

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: alexander <aleksiyantsa(at)gmail(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Multiple Sequence Number for One Column p.2
Date: 2016-02-02 23:07:42
Message-ID: CAKFQuwZaP-YT1y2LSw3XW6+UBsiWQmqa+89wjhSrOzH0iizfjA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Feb 2, 2016 at 4:28 AM, alexander <aleksiyantsa(at)gmail(dot)com> wrote:

> Hello
>
> I've met exactly the same problem as described here
> http://www.postgresql.org/message-id/95862fdc-eb2e-4533-8331-d49775b0ef8f@f2g2000yqf.googlegroups.com
> . For now, I use the same solution that was presented in the response
> http://www.postgresql.org/message-id/077DA5F9-F783-4388-BF19-42E582DC89EE@yahoo.com
> .
>
> In my case, I have a composite key composed of session ID and object ID.
> Session ID is a unique value. I'd like to have a separate auto incremental
> key for each session ID value. Therefore, I create a sequence for each
> session ID. The problem is that once the session has ended there won't be
> new values with its session ID, so, we have to clear obsolete sequences
> related to this ID from time to time.
>
> It's said in the last message that there are other solutions. It would be
> helpful for me to know the others if they exist in terms of PostgreSQL.
>
>
"...so, we have to clear obsolete sequences..." - why?

Your problem statement is too vague but I suspect you already have a
"session" table in your schema. You should have a column on that table
named something like "next available object id" and just serialize
read/write access to it. Depending on your needs (namely gap-less
requirements) whatever front-end session management layer you have could
acquire blocks of N integers and increment the value of "next...id" by 10
when it does so.

Honestly, the index for session+object is probably going to be fast enough
that you just query it when you need a new id.

Sessions themselves are not usually highly concurrent with
themselves...unless your architecture is novel in this respect you should
be able write a function that you can install as a BEFORE INSERT trigger
that will accomplish your goal without any serious performance hit. If
that is not good enough I would move assignment to the application layer
and provide a central location for the application to obtain the keys it
needs for the sessions that are active.

David J.


In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2016-02-02 23:11:21 Re: handling time series data
Previous Message Keith Brown 2016-02-02 23:04:14 handling time series data