Re: ctid access is slow - Mailing list pgsql-general

From Alvaro Herrera
Subject Re: ctid access is slow
Date
Msg-id 20050823182739.GB6139@surnet.cl
Whole thread Raw
In response to Re: ctid access is slow  ("Ilja Golshtein" <ilejn@yandex.ru>)
Responses Re: ctid access is slow  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Tue, Aug 23, 2005 at 05:30:31PM +0400, Ilja Golshtein wrote:
> Hi!
>
> >> Could anybody help me with this [artificial] query
> >>
> >> select ctid from aaa where ctid in (select ctid from aaa limit 10);
>
> [skipped]
>
> >I think using an indexed field would probably be faster for you,
> >especially if you have a PK on the table.
>
> I used to think ctid is the same as rowid in Oracle,
> where rowid access is the fastest. Is it wrong?

I don't know what is rowid internally, but in Postgres, ctid _is_ the
fastest way to access a (single) tuple, because it's the physical
address.  However, since the ctid datatype does not implement hashjoin
nor mergejoin, the plans are not as good when you have to access lots of
tuples.

> After all, why oid is faster then ctid?

Accessing single values by oid, even when there is an index, will be
slower than accessing single values by ctid; though in practice,
probably there won't be a measurable difference.

If you are too worried about it, you could look at what is needed to
implement hashjoin and mergejoin for ctids.  I take it it isn't trivial,
or it would be done already, but I don't think it's too hard (unless
there is an implementation detail that makes it impossible).

--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"Nadie esta tan esclavizado como el que se cree libre no siendolo" (Goethe)

pgsql-general by date:

Previous
From: Bruno Wolff III
Date:
Subject: Re: Where to get 8.1 beta test version?
Next
From: Alvaro Herrera
Date:
Subject: Re: OCFS released as GPL