As we started to discuss read-only transactions i remember two issues
and would like to discuss its too.

1) We have a bug in tracker related to transaction accounting in read-only databases.

As i remember we got an "can't find TIP page" error after processing some amount
of transaction in read-only database. This is because of tx numbers are increased (from
in-memory counter) but TIP pages are not added. We can add few more checks of course
but i think there is more interesting solutions.

The simplest we can do is to assign to all tx in read-only database the same number.
It was already proposed in fb-devel but was declined because it make not possible to
distinguish such transactions in monitoring tables.

I think about it more and my opinion is that assigning the same number for all tx in
readonly database have not valuated before benefit - it make cost of transaction start
near to zero. So i think we must investigate this solution again.
Especially if we will take in account next point :)

2) In web applications most transactions are short (lightweight) and read-only. If you
not agree - stop reading more :) So most part of cost of such transaction is transaction
start. We can eliminate big part of this cost by assigning the same number to the some
read-only transactions if they started sequentially. I.e.

start r\o tx, evaluate and assign number N
start r\o tx, assign number N
start r\o tx, assign number N
start r\o tx, assign number N
start r\w tx, evaluate and assign number N + 1
start r\o tx, evaluate and assign number N + 2
start r\o tx, assign number N + 2
start r\o tx, assign number N + 2
start r\o tx, assign number N + 2
...

We can also share tip cache between such r\o transactions (for read-committed ones).

This offer of course for r\w databases but it will have the same effect in r\o databases
and will cure bug mentioned above in (1).

Opinions ?

Regards,
Vlad