Re: LIKE, leading percent, bind parameters and indexes

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: LIKE, leading percent, bind parameters and indexes
Дата
Msg-id 20060527154612.GC7450@svana.org
обсуждение исходный текст
Ответ на Re: LIKE, leading percent, bind parameters and indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: LIKE, leading percent, bind parameters and indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: LIKE, leading percent, bind parameters and indexes  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
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 :(

So other than being careful with locking, you don't see any objections?
How about the suggestion of using a sequential index scan like the
recent changes to VACUUM in the case that there are no regular index
quals?

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Marko Kreen"
Дата:
Сообщение: Re: Inefficient bytea escaping?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: LIKE, leading percent, bind parameters and indexes