ScalarArrayOp advancing array keys

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
Subject: ScalarArrayOp advancing array keys
Date: 2007-12-12 13:22:03
Message-ID: 87r6hs3v5w.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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!

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2007-12-12 14:48:16 Re: Slow PITR restore
Previous Message Sam Mason 2007-12-12 13:20:31 foreign keys