Subject | Re: [Firebird-Architect] Table partitioning |
---|---|
Author | Ann W. Harrison |
Post date | 2004-11-19T16:25:08Z |
At 01:53 AM 11/19/2004, Jan Radl wrote:
The actual behavior depends on the architecture.
In Superserver and embedded on Windows, all activity occurs in
the context of a single server. In that case, each transaction
writes to pages in the shared cache. When a transaction commits,
all pages it changed are flushed to disk, whether or not other
uncommitted transactions have also changed those pages. The
multi-version concurrency control handles any problems of
uncommitted changes on disk, using the database itself as a sort
of before-image log.
In classic architecture, each connection maintains its own page
cache where it makes changes. If a page must be shared - like
an index pages when two connections are inserting data in the
same key range - the pages bounces around a bit, going through
disk on each trip. The connection that most recently changed the
page will have it in its cache. When another connection needs
the page, it signals the connection that has it. That connection
writes it to disk and releases its lock. The requesting connection
reads the page, makes its changes, and keeps the page in its cache
until its current transaction commits or some other connection
requests the page.
Regards,
Ann
> >Actually, inserts don't lock against each other in Firebird.
>Why i want it ? In case of lot of inserts in one table from dozen of
>clients, partitioned table increase performance due to paralel write to
>this table. If table is not partitioned the write processes are lock
>each other because of write to the same part of disk (db space).
The actual behavior depends on the architecture.
In Superserver and embedded on Windows, all activity occurs in
the context of a single server. In that case, each transaction
writes to pages in the shared cache. When a transaction commits,
all pages it changed are flushed to disk, whether or not other
uncommitted transactions have also changed those pages. The
multi-version concurrency control handles any problems of
uncommitted changes on disk, using the database itself as a sort
of before-image log.
In classic architecture, each connection maintains its own page
cache where it makes changes. If a page must be shared - like
an index pages when two connections are inserting data in the
same key range - the pages bounces around a bit, going through
disk on each trip. The connection that most recently changed the
page will have it in its cache. When another connection needs
the page, it signals the connection that has it. That connection
writes it to disk and releases its lock. The requesting connection
reads the page, makes its changes, and keeps the page in its cache
until its current transaction commits or some other connection
requests the page.
Regards,
Ann