From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | "Manoel Henrique" <mhenriquesgbd(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Research/Implementation of Nested Loop Join optimization |
Date: | 2008-07-26 00:26:43 |
Message-ID: | 4160.1217032003@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Manoel Henrique" <mhenriquesgbd(at)gmail(dot)com> 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 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.
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. A fairly
typical kernel behavior is that read-ahead is triggered by successive
read() requests without any intervening seek(), and this is impossible
for a backward scan.
(Yes, we do optimize out the seek calls in a forward scan. IIRC it's
done in fd.c.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | daveg | 2008-07-26 00:33:18 | Re: Adding WHERE clause to pg_dump |
Previous Message | Alvaro Herrera | 2008-07-26 00:15:48 | Re: Research/Implementation of Nested Loop Join optimization |