From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Ilja Golshtein <ilejn(at)yandex(dot)ru> |
Cc: | xzilla(at)users(dot)sourceforge(dot)net, pgsql-general(at)postgresql(dot)org |
Subject: | Re: ctid access is slow |
Date: | 2005-08-23 18:27:39 |
Message-ID: | 20050823182739.GB6139@surnet.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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)
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2005-08-23 18:30:21 | Re: OCFS released as GPL |
Previous Message | Bruno Wolff III | 2005-08-23 17:32:48 | Re: Where to get 8.1 beta test version? |