Consider a situation where there's an index on <x,y> and we're processing a where clause like:
WHERE x IN (1,2,3,4,5) AND y IN ('A','B','C','D') Assuming we use the index we loop through doing an index lookup for every combination of the two (generated) arrays. Except if I understand ExecIndexAdvanceArrayKeys() correctly we do it in what seems like a nonoptimal order. It seems we do index lookups in the order: <1,A> <2,A> <3,A> <4,A> <5,A> <1,B> <2,B> <3,B> <4,B> <5,B> <1,C> ... Is that right? Or are these array index info structs themselves in reverse order anyways? Wouldn't it make more sense and perhaps perform slightly better to iterate in the other order? That is, <1,A> <1,B> <1,C>... ? I've been discussing here what it would take to be able to use posix_fadvise() in the index lookup itself. The only reasonably proposal we have so far to do this would be to buffer up some number of index probes like this and send them off to index_getmulti() as a group. That would make it more important to do the above in the right order since a big part of the advantage of doing that would be avoiding the redundant index descents for adjacent index keys. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly