Dennis Bjorklund <db@zigo.dhs.org> writes:
> On 25 Aug 2004, Greg Stark wrote:
>
> > It's only allowed when the transaction is in READ UNCOMMITTED isolation level.
> > Something Postgres doesn't currently support. In fact I'm not aware of any SQL
> > database that supports it, though I'm sure there's one somewhere.
>
> Looks like mysql also supports it:
>
> http://dev.mysql.com/doc/mysql/en/InnoDB_transaction_isolation.html
>
> Together with the other replies we now have a whole bunch of databases
> that implements it.
Well it would be a pretty handy feature.
Several times I've seen people on the list trying to calculate how far some
big batch update or load had proceeded by looking at the sizes of files in the
data directory, estimating row sizes, and dividing.
That's a pretty kludgy method for doing what could be done cleanly and with
more flexibility by just running switching to read uncommitted mode and
selecting to see how many records had been inserted.
I don't know the details, but with postgres's model wouldn't it be a simply
matter of treating every tuple found as having been inserting or deleted
without checking to see if the transaction id in the tuple is committed? It
should be even easier than the normal read committed mode.
One danger would be for such "dirty" data leaking out into the rest of the
database. But I would be pretty happy with such a feature even if it meant no
inserts/deletes/updates could be performed while in that mode.
--
greg
