> I'd suggest using an optimistic-locking approach instead: don't lock
> at all, just rely on unique indexes to prevent duplicate insertions.
> Once in a while you will get a collision, and then you'll have to
> roll back your transaction and try again --- but if that only seldom
> happens, it's a lot faster than locking every time.
My table A (which can be big) is that:
A(TEXT AbsoluteURL, SERIAL Id) with Id as PRIMARY KEY
AbsoluteURL will contain strings like
"http://archives.postgresql.org/pgsql-general/"
If I declare AbsoluteURL as UNIQUE, do you think it will be good for the
efficient of the DB? Because when I insert a value in the table it could
take a long time to verify if this entry already exists or not. Am I wrong?
If I lock the table A, no other processus will acces to the table but
Postgresql won't have to verify if the entry already exists.
What is the best solution in your opinion?
Thanks for your help
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
>