Re: how to make an 'UNLOCK'?

>> 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(at)rocketmail(dot)com

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com