| Subject | Re: [Firebird-Architect] Feature request... |
|---|---|
| Author | Ann W. Harrison |
| Post date | 2004-05-27T15:17:35Z |
At 02:29 AM 5/27/2004, Jonathan Neve wrote:
versioning. The one you're describing is very basic - allows you to see
what was happening at 10:30 last Tuesday. That's OK for read-only
access, but suppose you want to fix something that happened last
Tuesday? Do you create an alternate future? For some applications - CAD,
CVS, etc., that's what you want. For others - accounting for example -
alternate futures are unwise.
current implementation of Firebird, it presents problems. There is no way
to determine a consistent view of old data. Firebird constructs a
consistent view for active transactions by keeping a list of "unsafe"
transactions, those that have rolled back and those that are still
active. The fact that one transaction number is higher than another
doesn't mean that the first transaction can see the work of the
second. The second could still be active. To get a consistent picture
of past versions, you need to know the order of commits. That information
is not available. Creating and maintaining it would have a significant
impact on system performance.
No doubt you've seen threads about the performance impact of long-running
transactions. When the number of back versions increases, indexes and data
locality suffer. The indexes fill with pointers to old versions, so index
selectivity goes down and index size goes up. Back versions of records
stop fitting on page with their most recent copy, so any operation, read or
write, requires reading multiple pages.
I understand that you've presented this as a feature request, but what
would you use it for?
Regards,
Ann
> >The larger problem is that different applications need different types of
>Hmm. Well, I guess you must be right. Jim said the same thing. But what
>specifically makes it impossible?
versioning. The one you're describing is very basic - allows you to see
what was happening at 10:30 last Tuesday. That's OK for read-only
access, but suppose you want to fix something that happened last
Tuesday? Do you create an alternate future? For some applications - CAD,
CVS, etc., that's what you want. For others - accounting for example -
alternate futures are unwise.
>It seems to me that if we make the syntax very general (no automaticRead-only access to back versions is probably safe, but in fact, in the
>restore of back versions of any such thing), it should be possible. If
>the old versions are simply made available for reading, then what could
>be the problem?
current implementation of Firebird, it presents problems. There is no way
to determine a consistent view of old data. Firebird constructs a
consistent view for active transactions by keeping a list of "unsafe"
transactions, those that have rolled back and those that are still
active. The fact that one transaction number is higher than another
doesn't mean that the first transaction can see the work of the
second. The second could still be active. To get a consistent picture
of past versions, you need to know the order of commits. That information
is not available. Creating and maintaining it would have a significant
impact on system performance.
No doubt you've seen threads about the performance impact of long-running
transactions. When the number of back versions increases, indexes and data
locality suffer. The indexes fill with pointers to old versions, so index
selectivity goes down and index size goes up. Back versions of records
stop fitting on page with their most recent copy, so any operation, read or
write, requires reading multiple pages.
I understand that you've presented this as a feature request, but what
would you use it for?
Regards,
Ann