[
https://issues.apache.org/jira/browse/DERBY-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693745#action_12693745
]
Tiago R. Espinha commented on DERBY-3842:
-----------------------------------------
I was just looking at ExternalSortFactory and MergeInserter and I think
sortBufferMax doesn't really matter at all unless we have the debug on. And it
seems like this is an expected behaviour.
Maybe this parameter isn't intended for actual use and it's just there for
testing sake? With the debug set to true the tests do use an external sort 100%
of the times...
And then there's this comment on ExternalSortFactory:
// RESOLVE - mikem change this to use estimatedRows and
// estimatedRowSize to come up with a smarter number for sortBufferMax
// than a fixed number of rows. At least 2 possibilities:
// 1) add sortBufferMaxMem which would be the amount of memory
// the sorter could use, and then just pick the number of
// rows as (sortBufferMaxMem / (estimatedRows * estimatedRowSize)
// 2) add sortBufferUsePercentFree. This would be how much of
// the current free memory can the current sort use.
//
which I think further supports my theory. Maybe it's not wise to let the user
choose a maximum value for their sortBuffer on a row-amount basis?
Also, how should I go regarding the test? Do I leave it with the debug
parameter set and just submit a patch?
> Convert
> "org.apache.derbyTesting.functionTests.tests.store.holdCursorExternalSortJDBC30.sql"
> to junit.
> ------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3842
> URL: https://issues.apache.org/jira/browse/DERBY-3842
> Project: Derby
> Issue Type: Test
> Components: Test
> Reporter: Junjie Peng
> Assignee: Tiago R. Espinha
> Attachments: derby-3842-1.patch, derby-3842-1.stat,
> derby-3842-tiago.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
