> I can think of a number of ways we might attack this, but none seem > especially attractive --- > > 1. Have the index AMs create and switch into a special memory context > for each call, rather than running in the main execution context. > I am not sure this is workable at all, since the AMs tend to think they > can create data structures that will live across calls (for example a > btree lookup stack). It'd be the most general solution, if we could > make it work. > > 2. Modify the index AMs so that the comparison function FmgrInfo is > preserved across a whole query. I think this requires changes to the > index AM API (index_insert for instance has no provision for sharing > data across multiple calls). Messy, and would likely mean an initdb. > It would probably be the fastest answer though, since lookups wouldn't > need to be done more than once per query.
#2 seems most natural in that it formalizes something that is common for lots of index methods. We are only in beta1, so I think we can initdb. > 3. Set up a long-lived cache internal to the array functions that can > translate element type OID to the needed lookup data, and won't leak > memory across repeated calls. This is not the fastest or most general > solution, but it seems the most localized and safest fix. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
