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!
