"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
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 fr
When you install the source tree (e.g. in folder \postgresql-8.3.x) you
will want to examine nodeMergejoin.c typically found in a path similar
to this:
\postgresql-8.3.x\src\backend\executor\nodeMergejoin.c
Here are the comments from the version on my machine:
/*
* INTERFACE ROUTINES
*
15 matches
Mail list logo
