On Thu, May 17, 2012 at 6:08 AM, Joshua Berkus <josh@agliodbs.com> wrote:
> As you can see, the indexonlyscan version of the query spends 5% as much time reading the data as the seq scan
version,and doesn't have to read the heap at all. Yet it spends 20 seconds doing ... what, exactly?
>
> BTW, kudos on the new explain analyze reporting ... works great!
Looks like timing overhead. Timing is called twice per tuple which
gives around 950ns per timing call for your index only result. This is
around what is expected of hpet based timing. If you are on Linux you
can check what clocksource you are using by running cat
/sys/devices/system/clocksource/clocksource0/current_clocksource
You can verify that it is due to timing overhead by adding timing off
to the explain clause. Or use the pg_test_timing utility to check the
timing overhead on your system. With hpet based timing I'm seeing
660ns timing overhead and 26.5s execution for your query, with timing
off execution time falls to 2.1s. For reference, tsc based timing
gives 19.2ns overhead and 2.3s execution time with timing.
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
