Re: LIKE, leading percent, bind parameters and indexes

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Rodrigo Hjort <rodrigo(dot)hjort(at)gmail(dot)com>, Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: LIKE, leading percent, bind parameters and indexes
Date: 2006-05-28 19:43:18
Message-ID: Pine.OSF.4.61.0605282236190.515623@kosh.hut.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 27 May 2006, Martijn van Oosterhout wrote:

> On Sat, May 27, 2006 at 10:57:05AM -0400, Tom Lane wrote:
>> * Up to now, the only functions directly invoked by an index AM were
>> members of index opclasses; and since opclasses can only be defined by
>> superusers, there was at least some basis for trusting the functions
>> to behave sanely. But if an index AM is going to invoke arbitrary
>> user-defined expressions then more care is needed. What's particularly
>> bothering me is the notion of executing arbitrary functions while
>> holding a buffer lock on an index page.
>
> Actually, for a first pass I was considering doing it within the
> nodeIndexScan.c/nodeBitmapScan.c and not within the AM at all. But I
> just remembered, the index interface has no way to return the actual
> values in the index, so you can't do that :(

This discussion reminds me of the idea to do index-only scans,
returning tuples directly from an index without hitting the heap
at all. MVCC is the main problem there, but it would be nice that
whatever you come up with here would be usable if we ever implement
index-only scans.

I don't know the planner internals, so this might not make any sense at
all, but how about having separate index scan and fetch nodes. Index scan
would return index tuples and fetch would get the corresponding heap
tuples. You could then have whatever you want between them, perhaps
deferring the fetch step until just before returning the rows to the
client.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Devrim GUNDUZ 2006-05-28 19:56:27 Re: anoncvs still slow
Previous Message Magnus Hagander 2006-05-28 19:25:09 Re: anoncvs still slow