Re: Research/Implementation of Nested Loop Join optimization

Yes, I'm relying on the assumption that backwards scan has the same cost as
forward scan, why shouldn't it?

Yet, all plan node types we are testing works with backwards scan (looking
on ExecSupportsBackwardScan). But, is there a easy way to make a query
execute only in backwards scan? How we can do that? Our first objective is
to make a backwards scan only and then test a forward-and-backward scan.

-- Manoel

On Thu, Jul 24, 2008 at 2:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Manoel Henrique" <mhenriquesgbd(at)gmail(dot)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
>