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)