From: | Jorge Godoy <jgodoy(at)gmail(dot)com> |
---|---|
To: | Chris <dmagick(at)gmail(dot)com> |
Cc: | PostgreSQL General ML <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Best approach for a "gap-less" sequence |
Date: | 2006-08-14 12:09:51 |
Message-ID: | 87veovsels.fsf@ieee.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Chris <dmagick(at)gmail(dot)com> writes:
> I'm not sure what type of lock you'd need to make sure no other transactions
> updated the table (see
> http://www.postgresql.org/docs/8.1/interactive/sql-lock.html) but "in theory"
> something like this should work:
>
> begin;
> select id from table order by id desc limit 1;
> insert into table (id, blah) values (id+1, 'blah');
> commit;
This is part of the solution, yes. But I would still need locking this table
so that no other concurrent transaction gets another "id". I don't want to
lock the main table -- as I believe you're suggesting -- because I want it to
be searchable and updatable while I'm inserting new data. I just can't have
gaps in the sequence but I don't want to restrict everything else here.
> P.S. I'm sure in older versions this query wouldn't use an index:
> select max(id) from table;
It doesn't. You'd have to do what you did: "order by <x> desc limit 1" to
have it using indexes...
> I'm not sure about 8.0+.. hence doing an order by the id desc limit 1.
I also have to test it... But I still keep using the "order by desc" syntax
:-)
Thanks for your answer,
--
Jorge Godoy <jgodoy(at)gmail(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Fuhr | 2006-08-14 12:16:06 | Re: Best approach for a "gap-less" sequence |
Previous Message | Tobias Herp | 2006-08-14 09:39:47 | Leaving out a schema from the dump/restore |