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
Good joke, but to be
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
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
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
:)
--
Jonah H. Harris,
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't it?
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 cost
as
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 forward scans
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, but to be serious:
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 spoiled
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, ...
A
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 patches claimed
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
@postgresql.org
Subject: [HACKERS] Research/Implementation of Nested Loop Join
optimization
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
to
*ExecMergeJoin. -cim 10/31/89
*/
*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
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
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 change
16 matches
Mail list logo
