>At October 15, 2004, 05:21, JD FitzGerald wrote:
> > What's the deal with the 10,000 thing?

At 08:08 AM 10/15/2004, Daniel Rail wrote:

>It's related on how Firebird manages it's own memory. I think
>Nickolay has been working on a better memory manager and it might be
>better in FB 2.0. But, I can't really confirm this, and I know that
>it was talked about on the devel list.

Actually, what we refer to as "memory management" in the engine is
the handling of the internal structures that represent metadata,
request state, etc. The page buffer cache is a different problem,
also addressed (differently) in Vulcan and Firebird 2. Originally,
when a transaction committed, pages it had changed were written in
random order unless there was an explicit dependency between two
pages.

At some point during the history of InterBase, some bright spark
decided that page should be written from cache in page order rather
than in the order the cache happens to hold them. That may or may
not be a good idea - it probably depends on the disk architecture.
However, the order is maintained with an index that gets extremely
unbalanced and very inefficient at about 10,000 entries.

Firebird 2 uses a more efficient index. Vulcan eliminates the index
and sorts the pages before writing them. Nickolay likes in-memory
indexes. Jim doesn't.

Regards,


Ann