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@sss.pgh.pa.us> wrote:
"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.
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
