| From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "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-27 15:46:12 |
| Message-ID: | 20060527154612.GC7450@svana.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-05-27 15:52:40 | Re: LIKE, leading percent, bind parameters and indexes |
| Previous Message | Marko Kreen | 2006-05-27 15:36:15 | Re: Inefficient bytea escaping? |