>> 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?
Well, it is a key, so it's already indexed, to validate if it exists or
not it would just do a key lookup which should be very fast. I don't
have the code to postgreSQL to say for sure, but I've never noticed a
speed hit on any databases I've used with unique (M$ SQL, Access,
MySQL) though I've not done large databases on postgres yet.
My opionion is you would not suffer a significant speed loss.
Regards,
Jim Langston
=====
Taz Master
mailto:tazmaster@rocketmail.com
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com