Subject | Re: [firebird-support] Why does Firebird write so much data for simple select queries? |
---|---|
Author | Ann Harrison |
Post date | 2011-10-27T19:22:40Z |
On Thu, Oct 27, 2011 at 11:11 AM, dsaunders1971 <dsaunders1971@...>wrote:
garbage collection is on and there are old record versions to remove.
I suspect from your other message that you are creating a new transaction
for each select. Every time you start a transaction, Firebird changes the
"next transaction" value on the database header page. That change must be
flushed to disk before any changes made by the transaction and before the
transaction commits. Every time you commit or rollback a transaction, the
final state of the transaction must be recorded on a transaction inventory
page and that change must be written to disk. There's a slight possibility
that recording the transaction's final state will require allocating a new
transaction inventory page, which causes a few other writes.
The way to avoid all this, assuming that your query is read only and the
only statement in the transaction, is to set the transaction state and
isolation to READ_ONLY and READ_COMMITTED. In that mode, the transaction
does not get a unique transaction identifier so it avoids writing the header
and transaction inventory pages.
Ann
[Non-text portions of this message have been removed]
> I have a question about why Firebird writes / or changes so much data inFirebird doesn't write anything to disk for a Select, unless cooperative
> the database file when you run a simple select query.
>
garbage collection is on and there are old record versions to remove.
I suspect from your other message that you are creating a new transaction
for each select. Every time you start a transaction, Firebird changes the
"next transaction" value on the database header page. That change must be
flushed to disk before any changes made by the transaction and before the
transaction commits. Every time you commit or rollback a transaction, the
final state of the transaction must be recorded on a transaction inventory
page and that change must be written to disk. There's a slight possibility
that recording the transaction's final state will require allocating a new
transaction inventory page, which causes a few other writes.
The way to avoid all this, assuming that your query is read only and the
only statement in the transaction, is to set the transaction state and
isolation to READ_ONLY and READ_COMMITTED. In that mode, the transaction
does not get a unique transaction identifier so it avoids writing the header
and transaction inventory pages.
>Good luck,
Ann
[Non-text portions of this message have been removed]