"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Manoel Henrique" <[EMAIL PROTECTED]> writes:
>>> Yes, I'm relying on the assumption that backwards scan has the same cost as
>>> forward scan, why shouldn't it?
>
>> Because hard drives only spin one direction
>
Ron Mayer <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> A backwards scan will get no such overlapping and thus be up to 2X
>> slower, unless the kernel is smart enough to do read-ahead for
>> descending-order read requests. Which seems not too probable.
> Linux's old adaptive readahead patche
Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
"Manoel Henrique" <[EMAIL PROTECTED]> writes:
Yes, I'm relying on the assumption that backwards scan has the same cost as
forward scan, why shouldn't it?
G...we expect that forward scans will result
in the kernel doing read-ahead, ...
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> Good joke, but to be serious: we expect that forward scans will result
>> in the kernel doing read-ahead, which will allow overlapping of
>> CPU work to process one page with the I/O to bring in the next page.
> I wonder if this is
Tom Lane escribió:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > "Manoel Henrique" <[EMAIL PROTECTED]> writes:
> >> Yes, I'm relying on the assumption that backwards scan has the same cost as
> >> forward scan, why shouldn't it?
>
> > Because hard drives only spin one direction
>
> Good joke, b
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Manoel Henrique" <[EMAIL PROTECTED]> writes:
>> Yes, I'm relying on the assumption that backwards scan has the same cost as
>> forward scan, why shouldn't it?
> Because hard drives only spin one direction
Good joke, but to be serious: we expect that fo
Joshua D. Drake escribió:
> On Fri, 2008-07-25 at 19:31 -0400, Jonah H. Harris wrote:
> > On Fri, Jul 25, 2008 at 6:10 PM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> > > "Manoel Henrique" <[EMAIL PROTECTED]> writes:
> > >
> > >> Yes, I'm relying on the assumption that backwards scan has the same co
On Fri, 2008-07-25 at 19:31 -0400, Jonah H. Harris wrote:
> On Fri, Jul 25, 2008 at 6:10 PM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> > "Manoel Henrique" <[EMAIL PROTECTED]> writes:
> >
> >> Yes, I'm relying on the assumption that backwards scan has the same cost as
> >> forward scan, why shouldn
On Fri, Jul 25, 2008 at 6:10 PM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Manoel Henrique" <[EMAIL PROTECTED]> writes:
>
>> Yes, I'm relying on the assumption that backwards scan has the same cost as
>> forward scan, why shouldn't it?
>
> Because hard drives only spin one direction
:)
--
Jona
"Manoel Henrique" <[EMAIL PROTECTED]> writes:
> Yes, I'm relying on the assumption that backwards scan has the same cost as
> forward scan, why shouldn't it?
Because hard drives only spin one direction
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about Enterpr
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 d
"Manoel Henrique" <[EMAIL PROTECTED]> 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 c
From: Manoel Henrique [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 23, 2008 1:47 PM
To: Dann Corbit
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Research/Implementation of Nested Loop Join
optimization
The nodeMergejoin.c is the code for the Merge Join isn`t it? I am trying
position to mark TESTOUTER
>
> *
> else
>
> *
> break// return to top of outer loop
>
> * }
>
> * }
>
> *}
*/
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Manoel Henrique
Sent: Wednesday, July 23, 2008 1:17 PM
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] Research/Implementation of Nested Loop Join
optimization
Hi! I`m a researcher from PUC-Rio (Brazil) and we`re studying
Hi! I`m a researcher from PUC-Rio (Brazil) and we`re studying about an
Joins, and we`d like to implement an optimization on the Nested Loop Join,
this optimization consists on while scanning the inner table, the iteration
would go from up-down then backwards(down-up) to take advantage of the
buffer
16 matches
Mail list logo
