Subject | Re: Re[2]: [Firebird-Architect] Re: Index structures |
---|---|
Author | Artur Anjos |
Post date | 2003-06-10T12:41:11Z |
Hi Jim,
commited.
Having several versions on the same record is something that I was expect.
What it's difficult to me to understand is using an index on a select after
some new records are post.
My english is very poor, so here is an example:
1) Open transaction
2) Post several new records.
3) Select data in a way that we get a mix of this new data and old data
--> We will use an index on this, so AFAIU the indexes must be updated
already, reflecting the new data
.... and at the same time:
1) Open another transaction
2) Select data (same select of the point 3)
So, AFAIU, this transaction will make the engine use the index for all the
data (non-commited records included) and after boolean filter this up
(removing non-commited records).
It will be hard to keep a well balanced tree in situations when records are
post, and most of the time roll-backed.
I will wait if Ann can point me out some doc about this, but your post was
very usefull.
Thank you,
Artur
> Updates are propagated to the indexes at verb time. This meaning that atany
> given time the index may reflect values from several versions of the sameThis answer one main concern: how it will use indexes on data that is not
> record.
> There really isn't any alternative to this, as a transaction must be able
> to find
> its uncommitted records as well as committed records.
commited.
Having several versions on the same record is something that I was expect.
What it's difficult to me to understand is using an index on a select after
some new records are post.
My english is very poor, so here is an example:
1) Open transaction
2) Post several new records.
3) Select data in a way that we get a mix of this new data and old data
--> We will use an index on this, so AFAIU the indexes must be updated
already, reflecting the new data
.... and at the same time:
1) Open another transaction
2) Select data (same select of the point 3)
So, AFAIU, this transaction will make the engine use the index for all the
data (non-commited records included) and after boolean filter this up
(removing non-commited records).
It will be hard to keep a well balanced tree in situations when records are
post, and most of the time roll-backed.
> If it seems intuitive, you don't understand it, and need to think about it:-) It really seems intuitive.
> some more.
I will wait if Ann can point me out some doc about this, but your post was
very usefull.
Thank you,
Artur