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

From Robert Treat
Subject Re: ctid access is slow
Date
Msg-id 200508230915.42155.xzilla@users.sourceforge.net
Whole thread Raw
In response to ctid access is slow  ("Ilja Golshtein" <ilejn@yandex.ru>)
Responses Re: ctid access is slow  (Michael Fuhr <mike@fuhr.org>)
Re: ctid access is slow  ("Ilja Golshtein" <ilejn@yandex.ru>)
List pgsql-general
On Tuesday 23 August 2005 08:39, Ilja Golshtein wrote:
> Hello!
>
> Could anybody help me with this [artificial] query
>
> select ctid from aaa where ctid in (select ctid from aaa limit 10);
>
> here is explained plan
>
>   Nested Loop IN Join  (cost=300000000.47..300325932.99 rows=10 width=6)
>   Join Filter: ("outer".ctid = "inner".ctid)
>   ->  Seq Scan on aaa  (cost=0.00..44457.98 rows=1250998 width=6)
>   ->  Materialize  (cost=0.47..0.57 rows=10 width=6)
>         ->  Subquery Scan "IN_subquery"  (cost=0.00..0.46 rows=10 width=6)
>               ->  Limit  (cost=0.00..0.36 rows=10 width=6)
>                     ->  Seq Scan on aaa  (cost=0.00..44457.98 rows=1250998
> width=6)
>
> There are 1250998 records in aaa.
>
> As you see it is pretty slow - actually this thing is faster
> even if I use oid instead of ctid.
> Inner query works promptly of course.
>
> Any clue?
>

I think using an indexed field would probably be faster for you, especially if
you have a PK on the table.  Barring that, make sure you have
vacuumed/analyzed and send us explain analyze output.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

pgsql-general by date:

Previous
From: "Ilja Golshtein"
Date:
Subject: ctid access is slow
Next
From: Michael Fuhr
Date:
Subject: Re: ctid access is slow