Re: ctid access is slow

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Ilja Golshtein <ilejn(at)yandex(dot)ru>, xzilla(at)users(dot)sourceforge(dot)net, pgsql-general(at)postgresql(dot)org
Subject: Re: ctid access is slow
Date: 2005-08-23 19:08:18
Message-ID: 4455.1124824098@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message John Lawler 2005-08-23 19:18:33 plpgsql: returning multiple named columns from function *simply*
Previous Message Alvaro Herrera 2005-08-23 18:30:21 Re: OCFS released as GPL