db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4771) Continue investigation of automatic creation/update of index statistics
Date Wed, 08 Dec 2010 21:45:01 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969506#action_12969506
] 

Dag H. Wanvik commented on DERBY-4771:
--------------------------------------

Hi Kristian, thanks for addressing my comments. Here:answers to your questions in connection
with my latest batch of comments:

> * Yes, but not at this level. I thought it would be nice to have a name for the transaction
to identify it in the transaction table.  I think some new methods must be added to be able
to name a transaction at this level, so I'm not sure if it is worth the trouble.  I'm keeping
the TODO for now, might remove it in the next iteration.
>   
>   Opinions?

Fine with me.

> * It isn't needed now. Since the interface is internal, and there is only one implementation
of it, I suppose the best action to take now is to remove it.  We can introduce it again later,
and then probably in a shape more like you have described. It feels a bit odd to say in the
JavaDoc that scheduling requests may be denied, and not have a way to learn if it happened
or not...
>   
>   Opinions?

Fine, too.

> * Added synchronization for runningThread in the finally-block.  The current code will
let the thread die and then create a new one on the next update request. I considered adding
a sleep before letting the thread die, in case a new request would come in quickly.
>   Opinions?

I guess this could be improved later if it turns out to be an issue. +1


> * Do you mean we should call TransactionResourceImpl#handleException explicitly here?
>   I think the comment meant to say that the daemon will be disabled elsewhere.  I'll
address this issue in the next iteration.

Great.


> * I think I meant to retry the whole operation, that is to add the unit of work to the
end of the queue or something. The way it is now, it will retry to get the locks, but if that
fails it will discard the unit of work.  Note that there is retry logic on several levels
here.  Since a new unit of work will be scheduled the next time a query using the index(es)
is compiled, I'll delete the TODO and keep the code as it is.  If this strategy turns out
to be inadequate, we can fix it later.

Ok, fine.


> Continue investigation of automatic creation/update of index statistics
> -----------------------------------------------------------------------
>
>                 Key: DERBY-4771
>                 URL: https://issues.apache.org/jira/browse/DERBY-4771
>             Project: Derby
>          Issue Type: Task
>          Components: SQL, Store
>    Affects Versions: 10.8.0.0
>            Reporter: Kristian Waagan
>            Assignee: Kristian Waagan
>         Attachments: autoindexstats.html, derby-4771-1a-prototype_code_dump.diff, derby-4771-1a-prototype_code_dump.stat,
derby-4771-1b-prototype_code_dump.diff, derby-4771-2a-prototype_lcc_code_dump.diff, derby-4771-2b-prototype_lcc_code_dump.diff,
derby-4771-2c-prototype_lcc_code_dump.diff, derby-4771-2d-prototype_lcc_code_dump.diff, DERBY-4771-2e-prototype.rar,
derby-4771-2e-prototype_lcc_code_dump.diff, Derby-4771-2f-AutomaticIndexStatisticsTest_wondows7.rar,
derby-4771-2f-prototype_lcc_code_dump-WORK-IN-PROGRESS.diff, derby-4771-2f-prototype_lcc_code_dump.diff,
derby-4771-2g-prototype_lcc_code_dump.diff, derby-4771-2h-prototype_lcc_code_dump.diff, derby.log,
error-stacktrace.out, rjall.out, rjall.out, rjall.out, rjall.rar, rjone.out
>
>
> Work was started to improve Derby's handling of index statistics. This issue tracks further
discussion and work for this task.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message