[
https://issues.apache.org/jira/browse/ASTERIXDB-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420368#comment-15420368
]
Michael J. Carey commented on ASTERIXDB-1556:
---------------------------------------------
Two final thoughts: If we change the data structure to make things "more
moveable", that would probably be bad - we would be making the normal case
suffer (more bloated) at the expense of something we hope will rarely or never
happen. So, we have to keep that in mind. Also, I agree that separate hash
tables make sense - it's how I think I'd have done it, too, if I'd been doing
it - just because it wouldn't have occurred to me to have a global one.
HOWEVER - I worry that that might be a bigger change? (And I'd like to contain
this one for now and have everyone working on our issues in "most-pressing
DESC" sort order.)
> Hash Table used by External hash group-by doesn't conform to the budget.
> ------------------------------------------------------------------------
>
> Key: ASTERIXDB-1556
> URL: https://issues.apache.org/jira/browse/ASTERIXDB-1556
> Project: Apache AsterixDB
> Issue Type: Bug
> Reporter: Taewoo Kim
> Assignee: Taewoo Kim
> Attachments: 2wayjoin.pdf, 2wayjoin.rtf, 2wayjoinplan.rtf,
> 3wayjoin.pdf, 3wayjoin.rtf, 3wayjoinplan.rtf
>
>
> When we enable prefix-based fuzzy-join and apply the multi-way fuzzy-join ( >
> 2), the system generates an out-of-memory exception.
> Since a fuzzy-join is created using 30-40 lines of AQL codes and this AQL is
> translated into massive number of operators (more than 200 operators in the
> plan for a 3-way fuzzy join), it could generate out-of-memory exception.
> /// Update: as the discussion goes, we found that hash table in the external
> hash group by doesn't conform to the frame limit. So, an out of memory
> exception happens during the execution of an external hash group by operator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
