Re: LIKE, leading percent, bind parameters and indexes
От | Heikki Linnakangas |
---|---|
Тема | Re: LIKE, leading percent, bind parameters and indexes |
Дата | |
Msg-id | Pine.OSF.4.61.0605282236190.515623@kosh.hut.fi обсуждение исходный текст |
Ответ на | Re: LIKE, leading percent, bind parameters and indexes (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: LIKE, leading percent, bind parameters and indexes
Re: LIKE, leading percent, bind parameters and indexes |
Список | 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
В списке pgsql-hackers по дате отправления: