Re: SeqScan costs

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SeqScan costs
Date: 2008-08-13 18:33:40
Message-ID: 87r68s933v.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Decibel!" == Decibel! <decibel(at)decibel(dot)org> writes:

Decibel> Roughly what I get on my MBP (I'm about a factor of 2
Decibel> slower). This makes me think it's an issue of having to slog
Decibel> through an entire page one row at a time vs just using the
Decibel> index. To test this I tested selecting i=200 (remember we
Decibel> start filling data at the back of the page, so 200 would
Decibel> actually be the front, and I'm assuming the first value that
Decibel> would be hit) vs i=1. With seqscans, I saw about a 10%
Decibel> difference. With index scans the difference was moot, but
Decibel> also note that now index scans are in-between seqscans in
Decibel> performance.

The problem is that by looking for a constant row, you're actually
eliminating the entire effect being tested, because the uncorrelated
subselect is run ONCE as an initplan, and the entire query time is
then spent elsewhere. The differences in runtime you're seeing are
pure noise (the fact that you had to increase the iteration count so
much should have been a clue here).

--
Andrew (irc:RhodiumToad)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2008-08-13 19:40:29 Re: Transaction-controlled robustness for replication
Previous Message Marko Kreen 2008-08-13 18:07:17 Re: Replay attack of query cancel