RE: [Firebird-devel] Nbackup

[Samofatov, N. <Nickolay@BroadViewSoftware.com>]

Hi,=20

> >2) precedence graph is costly to scan

> Are there measurements that show this?  If so, what is the=20
> nature of the problem?  There are characteristics of the=20
> precedence tree that could be exploited to speeds things up=20
> if this is a serious problem.  Long chains, for example, are=20
> very unusual.  Most chains are two bdbs (database -< pointer=20
> page, lower btree <- upper btree, data page <- space=20
> management page).  Longer chains come from fragmented very=20
> large records, which are long but very simple.  If=20
> information learned on the nature of a chain is maintained in=20
> the precedence node, it is very likely that much work could=20
> be skipped.

AFAIR, indices code may create long precedence chains in a couple cases.
See garbage_collect for example. There could be other places, I don't
remember.

> >6) page structure is very sparse and wastes a lot of memory
> >
> This requires explanation, please.

I'm talking about ~10% maintenance overhead for 4k pages most of which
is completely unnecessary.

> I've never like the idea behind NBAK. =20

JS> Sorry for sticking my nose in late in the discussion, but I don't
follow=20
JS> the development list.  I think I understand the proposed scheme, but

JS> could use a quick recap.  If I understand it correctly, it sounds
like a=20
JS> very clever scheme which, with perhaps a tweak or two here and
there,=20
JS> could have a few other interesting uses as a read/write wrapper
around a=20
JS> readonly database.  This could be quite interesting for access to a=20
JS> database distributed on a CDROM.  Or for debugging a database
without=20
JS> destroying the test vehicle.  All sorts of interesting uses come to
mind.

;-)

Nickolay