At 02:10 PM 5/1/02 -0400, Tom Lane wrote:
>Lincoln Yeoh <lyeoh@pop.jaring.my> writes:
> > My limited understanding of current behaviour is the search for a valid
> > row's tuple goes from older tuples to newer ones via forward links
>
>No. Each tuple is independently indexed and independently visited.
>Given the semantics of MVCC I think that's correct --- after all, what's
>dead to you is not necessarily dead to someone else.
But does Postgresql visit the older tuples first moving to the newer ones,
or the newer ones first? From observation it seems to be starting from the
older ones. I'm thinking visiting the newer ones first would be better.
Would that reduce the slowing down effect?
Anyway, are you saying:
Index row X entry #1 -> oldest tuple
...
Index row X entry #2 -> older tuple
...
Index row X entry #3 -> old tuple
...
Index row X entry #4 -> just inserted tuple
And a search for a valid tuple goes through each index entry and visits
each tuple to see if it is visible.
That seems like a lot of work to do, any docs/urls which explain this? Are
the index tuples for the same row generally in the same physical location?
Whereas the following still looks like less work and still compatible with
MVCC:
index tuple -> new tuple -> rolled back tuple -> old tuple -> older tuple.
Just one index tuple per row. The tuples are checked from newer to older
for visibility via backward links.
The docs I mentioned say updates use the forward links. Repeated updates
definitely slow down, so backward links might help?
Regards,
Link.