Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote:
> On 13.01.2011 16:51, Kevin Grittner wrote:
>> But we acquired a relation lock up front, when we determined that
>> this would be a heap scan, so we could short-circuit this whole
>> thing if within the heapgettup_pagemode function we could
>> determine that this was a scan of the whole relation.
>
> That sounds simple enough. Add a boolean field to HeapScanDesc,
> "rs_relpredicatelocked", and set it when you acquire the relation
> lock.
Heikki, I can't thank you enough. The fix is here:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=64ca508a0e2fa9c21dc76a5d6a5f549c27f511fa
The timings are now:
begin transaction isolation level repeatable read;
Time: 324.938 ms
Time: 228.045 ms
Time: 227.963 ms
begin transaction isolation level serializable;
Time: 311.954 ms
Time: 311.928 ms
Time: 311.848 ms
begin transaction isolation level serializable, read only;
Time: 227.471 ms
Time: 228.137 ms
Time: 227.778 ms
begin transaction isolation level serializable, read only,
deferrable;
Time: 227.899 ms
Time: 249.772 ms
Time: 228.026 ms
begin transaction isolation level repeatable read;
Time: 231.173 ms
Time: 245.041 ms
Time: 228.149 ms
I'm surprised the difference is still that high as a percentage, and
will investigate, but this seems survivable. When I do the math,
the difference comes out to 83.885 nanoseconds per row.
-Kevin
