Neil Conway <[EMAIL PROTECTED]> writes:
> Hmm, true. Perhaps then just hacking the hash node so that hash join
> pulls on it twice (the first time for a single tuple, the second time
> for the rest) is the way to go. Since the hash node is essentially an
> implementation detail of hash join, I don't feel _too_ bad about
> dirtying up its API a bit...
If you still have in mind to do this, I've just committed some changes
that could provide a reasonably clean framework for it. I invented a
"MultiExecProcNode" interface that's intended to be used to call plan
nodes that don't follow the return-one-tuple-at-a-time protocol.
What I intend to use this for is indexscans returning bitmaps of tuple
TIDs, but at the moment the sole member of the class is Hash.
I'm thinking you could implement the above by first calling ExecProcNode
(once) on the Hash node to pull the first tuple, and then calling
MultiExecProcNode (once) if you wanted the hash table built. In
anticipation of that, I left Hash connected to ExecProcNode, though
ExecHash() currently just errors out if called.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
