| Subject | Re: [firebird-support] Re: firebird on virtual server |
|---|---|
| Author | Ann W. Harrison |
| Post date | 2010-10-19T16:04:55Z |
On 10/19/2010 6:30 AM, Kjell Rilbe wrote:
flash memory for storage ... and that has its own problems with the
hot pages (Header, TIP, PIP) in the Firebird architecture.
The answer to the first question is longer. Firebird and InterBase
do not use a write-ahead log, which PostgreSQL and SQL Server do.
A write-ahead log has several benefits and one obvious drawback.
The drawback is that every change has to be written twice, once to
the log then once from the log to the main database storage.
One advantage, and something that Jim used in Netfrastructure and
Falcon, is that on commit, the database does sequential writes to
get all the dirty pages on disk, which is much faster than writing
pages in a specific order to their random locations on disk.
Another advantage is that database pages don't have to be written in
any specific order from the log to the database. After a crash, the
write-ahead log is replayed until all the pages are where they should
have been after the last commit in the log.
Another disadvantage, less obvious, is that there's a lot of
bookkeeping involved in knowing whether committed data (and whatever
else supports it) is in the log or on disk. Falcon suffered for
months from records that would be there, then gone, then back as
they went from memory to log to disk. It eventually worked, but
it wasn't easy.
So, to answer the question directly, other database don't do lots
of seeks during a commit because they commit to a write-ahead log
rather than specific page locations on the disk. My recollection
is that the disk-based version of Solid did the same thing.
Databases that come to MVCC late already have logging systems
which are easier to maintain than replace.
Cheers,
Ann
> Of course! But I've always wondered why Firebird does so many seeks forTo answer the second part first, you probably can't without going to
> each transaction commit. The disk head does a huge amount of
> buzzing/rumbling for each commit. Haven't experienced that with
> PostgreSQL or SQL Server, which are both MGA aren't they?
>
> So why doesn Firebird behave like this and how can we configure it to
> make it lose less time on disk seeks?
flash memory for storage ... and that has its own problems with the
hot pages (Header, TIP, PIP) in the Firebird architecture.
The answer to the first question is longer. Firebird and InterBase
do not use a write-ahead log, which PostgreSQL and SQL Server do.
A write-ahead log has several benefits and one obvious drawback.
The drawback is that every change has to be written twice, once to
the log then once from the log to the main database storage.
One advantage, and something that Jim used in Netfrastructure and
Falcon, is that on commit, the database does sequential writes to
get all the dirty pages on disk, which is much faster than writing
pages in a specific order to their random locations on disk.
Another advantage is that database pages don't have to be written in
any specific order from the log to the database. After a crash, the
write-ahead log is replayed until all the pages are where they should
have been after the last commit in the log.
Another disadvantage, less obvious, is that there's a lot of
bookkeeping involved in knowing whether committed data (and whatever
else supports it) is in the log or on disk. Falcon suffered for
months from records that would be there, then gone, then back as
they went from memory to log to disk. It eventually worked, but
it wasn't easy.
So, to answer the question directly, other database don't do lots
of seeks during a commit because they commit to a write-ahead log
rather than specific page locations on the disk. My recollection
is that the disk-based version of Solid did the same thing.
Databases that come to MVCC late already have logging systems
which are easier to maintain than replace.
Cheers,
Ann