Re: Is this a better MVCC.

On 7.1.x it definitely gets slower even for indexscans. e.g. 60 updates/sec
dropping to 30 then to 20 over time.

Is this fixed for 7.2?

If not, is it possible to make the pointer point to the latest row instead
of the most obsolete one, and having the newer rows point to the older
ones, instead of the other way round (which seems to be happening with
7.1)? I suppose this could make updates slower - have to update indexes?
But selects would be faster (other than cases where there are a lot of
uncommitted updates outstanding).

If that is not possible (or updating the index too painful), how about
having the first pointer point to first row which then points to latest
row, which then points to subsequent older rows. That way the miss penalty
is reduced.

It seems reasonable to me that the newer rows should be more visible-
unless more people update rows and then rollback rather than update and
then commit.

I'm missing something out right? :)

Regards,
Link.

At 09:15 AM 4/16/02 -0400, Tom Lane wrote:
>mlw <markw(at)mohawksoft(dot)com> writes:
> > Now, what if we did it another way, copy the old version of the row
> into the
> > new row and update the tuple in place?
>
>I don't think we can get away with moving the extant tuple. If we did,
>a concurrent scan that should have found the old tuple might miss it.
>(This is why VACUUM FULL needs exclusive lock to move tuples.)
>
>It's fairly unclear whether this would actually buy any performance
>gain, anyway. In the case of a seqscan I don't see that it makes any
>difference on average, and in the case of an indexscan what matters is
>the index ordering not the physical location. (In this connection,
>btree indexes already do the "right thing", cf comments for
>_bt_insertonpg.)