Subject | Re: Why does Firebird write so much data for simple select queries? |
---|---|
Author | dsaunders1971 |
Post date | 2011-10-28T19:14:57Z |
> The way to avoid all this, assuming that your query is read only and theCould you please clarify the format of the SQL to achieve this
> 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.
Many thanks
David
--- In firebird-support@yahoogroups.com, "ma_golyo" <ma_golyo@...> wrote:
>
> Hi!
>
> "Firebird doesn't write anything to disk for a Select,..."
>
> That's not true. Firebird writes the resultset on HDD when SELECT contains ORDER BY (maybe PLAN SORT affect that), and does the ordering in this file.
>
>
> --- In firebird-support@yahoogroups.com, Ann Harrison <aharrison@> wrote:
> >
> > On Thu, Oct 27, 2011 at 11:11 AM, dsaunders1971 <dsaunders1971@>wrote:
> >
> > > I have a question about why Firebird writes / or changes so much data in
> > > the database file when you run a simple select query.
> > >
> >
> > Firebird doesn't write anything to disk for a Select, unless cooperative
> > 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]
> >
>