Re: Performance critical technical key

Bruno Wolff III wrote:

>>> Using a sequence shouldn't be slow.

Thanks - that's the main thing I need to know.

>>> The main potential problem is that it will make the session IDs
>>> guessible if you don't take any other steps. That may or may not
>>> be a problem.

Thanks for the warning, but I won't be using the sequence number as
the session id: as you say, not a safe thing to do. The session record
key persists from session to session: it is used to link sessions with
browsers and with user accounts. The session key will be a random 32
character key generated for each session.

Christopher Browne wrote:

>>> Why, in particular, would you expect the sequence to slow down
>>> inserts? They don't lock the table.

I was assuming that generating the sequence number was expensive: it
is some other DBs I have used. That was why I was thinking of
providing a unique id via a random string. But a practical test shows
that in PG it is pretty fast, so there is not need.

>>> Note that if you're really doing a lot of INSERTs in parallel, you
>>> might find it worthwhile to configure the sequence to cache some
>>> number of entries so that they are pre-allocated and stored in memory
>>> for each session (e.g. - for each connection) for quicker access. See
>>> the documentation for "create sequence" for more details...

I think that would be worthwhile.

Thanks for the input, folks.

------------------
Geoff Caplan
Vario Software Ltd
(+44) 121-515 1154