>>>>> "Decibel!" == Decibel! <[EMAIL PROTECTED]> 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) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
