[
https://issues.apache.org/jira/browse/PHOENIX-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15450589#comment-15450589
]
Lars Hofhansl commented on PHOENIX-3228:
----------------------------------------
Yeah... Will run the tests... Didn't even compile, yet :)
I'd expect that with small data size (but big enough to reach the smaller max
size) you'd see the index table distributed over fewer regions. But that
argument doesn't hold as then we'd also have to apply the same logic to the
main table - something more smaller region might better in certain
circumstances.
Perhaps the angst stems from the fact that a full scan over the index table
could be slower than a full scan over the main table, since that table is
probably spread over slightly more regions...?
> Index table are configured with a custom/smaller MAX_FILESIZE
> -------------------------------------------------------------
>
> Key: PHOENIX-3228
> URL: https://issues.apache.org/jira/browse/PHOENIX-3228
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 4.9.0, 4.8.1
>
> Attachments: 3228-remove.txt, 3228.txt
>
>
> I do not think we should do this. The default of 10G is chosen to keep HBase
> happy. For smaller tables or initially until the index gets large it might
> lead to more index regions and hence be able to utilize more region server,
> but generally, this is not the right thing to do.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
