From: Hannu Krosing <hannu@skype.net>
To: Greg Stark <gsstark@mit.edu>
Cc: josh@agliodbs.com, David Fetter <david@fetter.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: More thoughts about planner's cost estimates
Date: Sat, 03 Jun 2006 22:18:14 +0300
Message-ID: <1149362295.3889.29.camel@localhost.localdomain> (raw)
In-Reply-To: <87pshre28d.fsf@stark.xeocode.com>
References: <14821.1149104747@sss.pgh.pa.us>
<20060602010412.GI10906@fetter.org>
<87ac8vfptu.fsf@stark.xeocode.com>
<200606021223.35168.josh@agliodbs.com>
<87pshre28d.fsf@stark.xeocode.com>
Ühel kenal päeval, R, 2006-06-02 kell 16:23, kirjutas Greg Stark:
> And a 5% sample is a pretty big. In fact my tests earlier showed the i/o from
> 5% block sampling took just as long as reading all the blocks. Even if we
> figure out what's causing that (IMHO surprising) result and improve matters I
> would only expect it to be 3-4x faster than a full scan.
You should not be surprised by this once you visualise what happens at
the disk level with all those platters spinning and heads moving :)
Disks can read at full rotation speed, so skipping (not reading) some
blocks will not make reading the remaining blocks from the same track
faster. And if there are more than 20 8k pages per track, you still have
a very high probablility you need to read all tracks..
You may be able to move to the next track a little earlier compared to
reading all blocks, but then you are likely to miss the block from next
track and have to wait a full rotation.
You will get some win from skipping pages only once your % falls so low
that you can also skip a significant number of tracks.
> http://archives.postgresql.org/pgsql-hackers/2006-01/msg00285.php
Your test program could have got a little better results, if you had
somehow managed to tell the system all the block numbers to read in one
go, not each time the next one after hetting the previous one. In
current version it is quite likely that it had to wait several disk
rotations for even the sectors from the same track, as for small steps
it may have missed the next sector. It does not apply for disks which
always read a full track in RAM cache, but even there all tracks are
actually read.
The fact that 5% was not slower than seqscan seems to indicate that
actually all track reads were cached inside the disk or controller.
--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: hannu@skype.net, gsstark@mit.edu, david@fetter.org, tgl@sss.pgh.pa.us
Subject: Re: More thoughts about planner's cost estimates
In-Reply-To: <1149362295.3889.29.camel@localhost.localdomain>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox