Phoenix already supports columns at read-time using the syntax without the
EXTENDS keyword as Julian indicated:
SELECT * FROM Emp (favoriteBand VARCHAR(100), golfHandicap INTEGER)
WHERE goldHandicap < 10;
Changing this by requiring the EXTENDS keyword would create a backward
compatibility
Phoenix since I assume the sequence would
> need to be global and unique (and also distributed).
>
> --
> Jacques Nadeau
> CTO and Co-Founder, Dremio
>
> On Tue, Oct 20, 2015 at 9:24 AM, James Taylor <jamestay...@apache.org>
> wrote:
>
> > Does Drill support
re of this Scan list might be helpful for 2), or we may have
>>>> some Logical representation for this. Otherwise, we can simply flatten this
>>>> list to a one-dimensional list as we do now (in my ci yesterday).
>>>>
>>>>
>>>>
>>&g
result was:
> 6 0
> 7 0
> 8 0
> 9 0
> 0 0
> 1 100
> 2 100
> 3 100
> 4 100
> 5 100
>
> Here I just tried another one "SELECT e2, count(*) FROM a.beer GROUP BY
> e2".
> Similarly, the expected result should have group-by keys from 0 to 99,
&g
mail.com>
>> wrote:
>> > The partial aggregate seems to be working now, with one interface
>> extension
>> > and one bug fix in the Phoenix project. Will do some code cleanup and
>> > create a pull request soon.
>> >
>> > Still there was
Maryann,
I believe Jacques mentioned that a little bit of refactoring is required
for a merge sort to occur - there's something that does that, but it's not
expected to be used in this context currently.
IMHO, there's more of a clear value in getting the aggregation to use
Phoenix first, so I'd
