You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@asterixdb.apache.org by "Peeyush Gupta (Jira)" <ji...@apache.org> on 2024/08/23 17:49:00 UTC
[jira] [Resolved] (ASTERIXDB-3410) OOM Error with Heavily Nested Queries
[ https://issues.apache.org/jira/browse/ASTERIXDB-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peeyush Gupta resolved ASTERIXDB-3410.
--------------------------------------
Resolution: Fixed
> OOM Error with Heavily Nested Queries
> -------------------------------------
>
> Key: ASTERIXDB-3410
> URL: https://issues.apache.org/jira/browse/ASTERIXDB-3410
> Project: Apache AsterixDB
> Issue Type: Bug
> Components: COMP - Compiler
> Reporter: Glenn Justo Galvizo
> Priority: Major
> Labels: triaged
>
> Something I came across while trying to use AFrame with AsterixDB ([https://dzone.com/articles/dataframes-with-big-data-in-couchbase]). A pattern used by AFrame and early versions of Graphix involved repeatedly nesting queries:
> SELECT VALUE OBJECT_REMOVE(t, 'categories')
> FROM (
> SELECT t.*, to_bigint(contains(categories, "Home Services")) AS `Home Services`
> FROM (
> SELECT t.*, to_bigint(contains(categories, "Bars")) AS `Bars`
> FROM ...
>
> .
> .
> .
>
> ) t
> ) t
>
> Unfortunately, for heavily nested queries, AsterixDB throws an out of memory error. This was an issue I faced with the compiler, not the runtime (I ran this with EXPLAIN, and I still got the OOM error).
>
> Potential remedy: we do have a decorrelation Algebricks rule, but it may (potentially) be less memory intensive to have an AST-level rule that tries to do the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)