Thanks for taking the time to go through the loooong mail. My responses inline.
Mamta
On 5/24/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
Mamta Satoor wrote:
[snip of first ten paragraphs]
This is very useful, but I have two quick clarifying questions on the
11th paragragh.
> In order to improve Derby's performance in conglomerate maintenance
> area, in
> Derby 10.0, few changes were made in
> org.apache.derby.impl.sql.execute.CreateIndexConstantAction.executeConstantAction ,
>
> so that if a new (backing)index was detected to be a duplicate of an
> existing index, then rather than creating a new conglomerate for it, the
> new
> index would share the conglomerate that was already created for the
> existing
> duplicate index.
Q1) For this next sentence, should the first 'SYSCONGLOMERATES' be
replaced with 'SYSCONSTRAINTS'?
Sorry, I meant to say SYSCONSTRAINTS instead of the first SYSCONGLOMERATES.
> So, an entry will be made into SYSCONGLOMERATES for the
> new constraint and an entry will be made into SYSCONGLOMERATES for the new
> constraint but the CONGLOMERATEID of the new constraint will be same as the
> CONGLOMERATEID of the existing duplicate index.
Q2) Does this mean that the CONGLOMERATEID is no longer unique within
SYSCONGLOMERATES as described in the reference manual?
Yes, CONGLOMERATEID are no longer unique within SYSCONGLOMERATES and hence the reference manual is not correct. I noticed this during my research but wanted to thrash out my findings with the community before opening a jira entry for the reference manual.
It seems that there is now a separation of congomerates into logical
congomerates (rows in SYSCONGLOMERATES) and physical conglomerates
(files on disk). But what you describe has the CONGLOMERATEID being the
physical identifier when it seems it should be a unique identifier for
the logical conglomerate. I would have thought the CONGLOMERATENUMBER
would be the physical identifier, thus in the situation you describe I
would expect two rows in SYSCONGLOMERATES with the same
CONGLOMERATENUMBER but unique CONGLOMERATEIDs.
The duplicate rows do have the same CONGLOMERATENUMBER which corresponds to the physical conglomerate. But the CONGLOMERATEID which could be thought of as logical conglomerate is not unique in SYSCONGLOMERATES. If we change the CONGLOMERATEID to be a unique key in SYSCONGLOMERATES by changing the code in
CreateIndexConstantAction somehow, then we will not have to change the metadata query in anyways and the reference manual will not have to change for the release in which the fix will go. If we decide not to backport the fix in older Derby releases, then we should fix the reference manual for those releases.
Thanks,
Mamta
Thanks,
Dan.
