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

From Tom Lane
Subject Re: ctid access is slow
Date
Msg-id 4455.1124824098@sss.pgh.pa.us
Whole thread Raw
In response to Re: ctid access is slow  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: ctid access is slow  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
List pgsql-general
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> 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).

It wouldn't be hard that I can see (just build hash and btree opclasses
for tid), but I'm pretty unclear on why bother.  There's no use-case for
cross-table joins involving ctid, since you couldn't usefully store a
ctid referencing another table.  The example Ilja showed was quite
artificial and should not convince anyone to expend effort on this.
Perhaps there are more convincing examples, but let's see one.

            regards, tom lane

pgsql-general by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: OCFS released as GPL
Next
From: John Lawler
Date:
Subject: plpgsql: returning multiple named columns from function *simply*