Re: Couple of design questions

Hi,
For the first question , having about 20,000 rows seems it will work fine.
(I do have about 100,000 rows table working fine.)
For the second, sure PG has enough locking some look for MVCC feature at the
PG docs(chapter 10).

>Will SELECT ... FOR UPDATE help me out here?
"However, take into account that SELECT FOR UPDATE will modify selected rows
to mark them and so will results in disk writes.
Row-level locks don't affect data querying. They are used to block writers
to the same row only. "

>Is there a way to
>check and see if a row is locked and ignore locked rows in another
>SELECT... FOR UPDATE?
I don't think this would be a safe way. ie: if user A made a select for
update , and then forgot to submit (commit) what would happen? the selected
rows would stay locked  for ever !?!
So IMO ,it would be safer if user A make a simple select ( showing it in an
HTML form ) and then make a seperate update (using HTML input).At this case
you will still have the risk of update error( if user B had made
simultanious updates ), but still seems safer.

Regards
Omid Omoomi


________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com