[
https://issues.apache.org/jira/browse/ASTERIXDB-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17733548#comment-17733548
]
ASF subversion and git services commented on ASTERIXDB-3213:
------------------------------------------------------------
Commit 4f6da369855ac89f0c0f34c1f10463cf797005bc in asterixdb's branch
refs/heads/master from Wail Alkowaileet
[ https://gitbox.apache.org/repos/asf?p=asterixdb.git;h=4f6da36985 ]
[MULTIPLE ISSUES] Fixes for handling anti-matters in columnar datasets
- user model changes: no
- storage format changes: no
- interface changes: yes
Details:
- ASTERIXDB-3214: Avoid skipping non-key columns when
anti-matter was encountered
- ASTERIXDB-3213: Use single PK reader for both the
cursor and the assembler
- ASTERIXDB-3212: Account for offset sizes for
variable-length PKs in columnar datasets
Change-Id: If7dec034a2d75c80688523b19be6fdc38f077a65
Reviewed-on: https://asterix-gerrit.ics.uci.edu/c/asterixdb/+/17599
Integration-Tests: Jenkins <[email protected]>
Tested-by: Jenkins <[email protected]>
Reviewed-by: Wail Alkowaileet <[email protected]>
Reviewed-by: Murtadha Al Hubail <[email protected]>
> Use only a single PK reader for both the cursor and the assembler
> -----------------------------------------------------------------
>
> Key: ASTERIXDB-3213
> URL: https://issues.apache.org/jira/browse/ASTERIXDB-3213
> Project: Apache AsterixDB
> Issue Type: Bug
> Components: RT - Runtime
> Affects Versions: 0.9.9
> Reporter: Wail Y. Alkowaileet
> Assignee: Wail Y. Alkowaileet
> Priority: Major
> Fix For: 0.9.9
>
>
> Previously, we used two separate primary key readers
> * One for the cursor
> *
> -- Its position maintained by the cursor
> * And one for assembler (if the primary key is requested – like in SELECT *)
> *
> -- Its position maintained by calling *IColumnValuesReader#skip(int)*
> In the previous approach, maintaining the positions of two primary key(s)
> readers were messy, as we needed to re-sync the assembler reader with the
> cursor PK reader. The reason is that anti-matters are handled at the cursor
> level. When anti-matters are processed, they are skipped – making the
> assembler PK reader out of sync.
> {_}Additionally, maintaining two readers that are decoding the same values
> (twice) is unnecessary{_}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
