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
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
