Re: Research/Implementation of Nested Loop Join optimization - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Research/Implementation of Nested Loop Join optimization
Date
Msg-id 20189.1216878555@sss.pgh.pa.us
Whole thread Raw
In response to Re: Research/Implementation of Nested Loop Join optimization  ("Manoel Henrique" <mhenriquesgbd@gmail.com>)
Responses Re: Research/Implementation of Nested Loop Join optimization  ("Manoel Henrique" <mhenriquesgbd@gmail.com>)
List pgsql-hackers
"Manoel Henrique" <mhenriquesgbd@gmail.com> writes:
> The nodeMergejoin.c is the code for the Merge Join isn`t it? I am trying to
> find a way to change the Nested Loop Join, It would be more like on
> nodeNestloop.c when rescanning the inner plan, (second time scanning the
> inner plan and so on) he`d change the scan direction, If the scan direction
> was from first tuple to last tuple it would go backwards, if it was from
> last to first it would go forward... The code I`m looking atm is from 8.3.1
> , seems to have some kind of direction manager but doesn`t seems to be in
> use.

I find this a bit dubious.  If the inner rel is small enough to fit in
memory then it buys nothing.  If not, then you win only to the extent
that a pretty large fraction of the inner rel fits in memory.  In any
case you are relying on the assumption that backwards scan is just as
efficient as forward scan, which seems to me to be a pretty large
assumption --- we expect forward seqscans to get a performance boost
from kernel readahead, but I'd be surprised if the kernel recognized
what was happening in a backwards scan.

Note also that backwards scan doesn't work at all in some plan
node types (cf ExecSupportsBackwardScan).  You'd need to check
what the inner input node was before trying this.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: [PATCHES] WITH RECUSIVE patches 0723
Next
From: Tom Lane
Date:
Subject: Re: issues/experience with building postgres on Windows