[ 
https://issues.apache.org/jira/browse/ASTERIXDB-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17406286#comment-17406286
 ] 

ASF subversion and git services commented on ASTERIXDB-2829:
------------------------------------------------------------

Commit 36fd16eefd367ef7d63e2158beeadeefd1760529 in asterixdb's branch 
refs/heads/master from ggalvizo
[ https://gitbox.apache.org/repos/asf?p=asterixdb.git;h=36fd16e ]

[ASTERIXDB-2829][IDX] Adding support for composite atomic-array indexes

- user mode changes: no
- storage format changes: no
- interface changes: no

Adding support for composite atomic-array indexes. The only prefix
queries supported must involved the array component on closed fields.
Also expanded the test coverage to explore more paths (w.r.t the
optimizer).

Change-Id: I2579a9da8dcd8b8c808b20883f356aab3e1a7095
Reviewed-on: https://asterix-gerrit.ics.uci.edu/c/asterixdb/+/12764
Integration-Tests: Jenkins <[email protected]>
Tested-by: Jenkins <[email protected]>
Reviewed-by: Dmitry Lychagin <[email protected]>


> Add Support for Composite Atomic-Array Indexes
> ----------------------------------------------
>
>                 Key: ASTERIXDB-2829
>                 URL: https://issues.apache.org/jira/browse/ASTERIXDB-2829
>             Project: Apache AsterixDB
>          Issue Type: Improvement
>          Components: IDX - Indexes
>            Reporter: Glenn Justo Galvizo
>            Assignee: Glenn Justo Galvizo
>            Priority: Major
>
> Currently array indexes only support indexing on the elements of an array. It 
> would be beneficial to add atomic fields as prefix(es) / suffix(es) to an 
> array index, to allow for more queries to use an array index as an access 
> method.
>  
> As it stands composite array indexes are allowed in the grammar and _should_ 
> be maintainable (i.e. bulk loading, insert, delete, and upserts should work), 
> but care must be given when recognizing that the index is applicable. In the 
> IntroduceSelectAccessMethodRule, we currently only attempt to optimize a 
> single SELECT (and thus, only keep context for that specific SELECT)- but 
> applicable composite atomic-array index queries have SELECTs that span 
> multiple levels (one before the unnest and one after).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to