On Tue, Feb 21, 2006 at 02:41:13AM -0800, Chad wrote:
> Thanks Martijn/Alban,
>
> This look interesting. I'll make some time to try this problem out
> using your approach.
> I have a few questions like:
> -Could I skip the FETCH FORWARD and go straight to the FETCH BACKWARD
> i.e. declare cursor to be at "Mal" and go backwards from there or is
> the cursor limited to going backward only as far as "Mal"?
Only as far back as "Mal". However, if you set your original query to
ORDER BY blah DESC, then FETCH FORWARD would scan backward through the
index.
> -Does the DB avoid transferring the data until the FETCH command?
Of course. It would kind of defeat the purpose to do otherwise.
> -When rows change in between opening the cursor and fetching the
> changed rows, will the FETCH retrieve the new data or is a snapshot
> taken when the cursor is declared ?
Standard visibility rules apply. READ COMMITTED shows anything
committed, even after you've started. SERIALIZABLE gives you a
consistant snapshot.
> -What about concurrency? If a cursor is kept open while other
> transactions change the same table or does it cause those writer
> transactions to block? Perhaps this is configurable.
Some as normal. PostgreSQL doesn't acquire any locks for plain SELECTs
so no risk there...
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
