phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <>
Subject [jira] [Assigned] (PHOENIX-3156) Bug in DistinctPrefixFilter
Date Sat, 06 Aug 2016 04:08:20 GMT


Lars Hofhansl reassigned PHOENIX-3156:

    Assignee: Lars Hofhansl

> Bug in DistinctPrefixFilter
> ---------------------------
>                 Key: PHOENIX-3156
>                 URL:
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Lars Hofhansl
>            Assignee: Lars Hofhansl
>            Priority: Blocker
>             Fix For: 4.8.0
>         Attachments: 3156-v2.txt, 3156.txt
> There's a corner case I found where a DISTINCT and GROUP BY query along a prefix of a
compound row key might return incorrect results.
> The filter relies on seeing the _0 column absolutely last, and not seeing all Cells that
should be filtered. That break in two scenarios:
> # we have a table with key (key1, key2, key3) and columns (c1 and c2). Now construct
a WHERE <a clause that always matches c1>, <a clause that filters by c2) GROUP BY
key1, key2. Now the filter would mis-skip when it sees the Cell for c1.
> # we force lower key column names. In that case those would sort after the _0 column.
The DistinctPrefixFilter would see the _0 column first and skip.
> In both case we are effectively changing the order in which the filters are applied.
The DistinctPrefixFilter is no longer for the row.
> I can fix #1 (by ignoring all Cells other than then _0 one). I do not know how to fix
case #2.
> I think this is a blocker and we may have to undo the entire DISTINCT and GROUP BY prefix
> [], [~giacomotaylor], [~samarthjain].

This message was sent by Atlassian JIRA

View raw message