Re: ctid access is slow

--- Tom Lane <tgl@sss.pgh.pa.us> wrote:

> "Jim C. Nasby" <jnasby@pervasive.com> writes:
> > I believe that's not necessarily true. If you
> select a tuple and it's
> > ctid and it's updated more than once with a vacuum
> in-between I believe
> > it could end up back in the same position, which
> would mean the same
> > ctid.
>
> This is the reason for the recommendation that you
> don't trust a TID for
> longer than one transaction.  If you select a row
> and see it has TID
> such and such, and then later try to
> fetch/update/delete that row by
> TID, the worst that can happen is that you'll not
> find the row because
> some other xact has already updated or deleted it.
> You can not find
> a different row in the TID slot, because VACUUM will
> not have removed
> a row that is possibly still visible to your
> transaction.  (VACUUM
> has no idea whether you're running under
> SERIALIZABLE rules or not,
> and so it takes the conservative approach that any
> row you could ever
> possibly have seen as good is still interesting.)
> But this guarantee
> only lasts as long as your current transaction.
>
>             regards, tom lane
>

Just in case anyone following this thread gets a
little confused, my response was somewhat tangential
to the main discussion; I was talking of fetching the
record by primary key or such, and then comparing the
ctid values.  Agreed that any other valid use of ctid
is dubious.




__________________________________
Yahoo! Mail for Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail