[
https://issues.apache.org/jira/browse/PHOENIX-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16362510#comment-16362510
]
John Leach commented on PHOENIX-4602:
-
[~comnetwork] Thank you for the pointer in the code
[
https://issues.apache.org/jira/browse/PHOENIX-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16362414#comment-16362414
]
John Leach commented on PHOENIX-4602:
-
[~comnetwork] I am new to Phoenix, but when I look
aggregations and handle intermediate results)
4. Yarn Support: No except for MapReduce and Index Creation Bits
5. Resource Management: ? Thread pool w/ first in first out?
Is this accurate?
Regards,
John Leach
John Leach created PHOENIX-3321:
---
Summary: TPCH 100G: Query 21 Missing Equi-Join Support
Key: PHOENIX-3321
URL: https://issues.apache.org/jira/browse/PHOENIX-3321
Project: Phoenix
Issue Type
John Leach created PHOENIX-3320:
---
Summary: TPCH 100G: Query 20 Execution Exception
Key: PHOENIX-3320
URL: https://issues.apache.org/jira/browse/PHOENIX-3320
Project: Phoenix
Issue Type: Bug
John Leach created PHOENIX-3319:
---
Summary: TPCH 100G: Query 15 with view cannot parse
Key: PHOENIX-3319
URL: https://issues.apache.org/jira/browse/PHOENIX-3319
Project: Phoenix
Issue Type: Bug
John Leach created PHOENIX-3318:
---
Summary: TPCH 100G: Query 13 Cannot Parse
Key: PHOENIX-3318
URL: https://issues.apache.org/jira/browse/PHOENIX-3318
Project: Phoenix
Issue Type: Bug
John Leach created PHOENIX-3317:
---
Summary: TPCH 100G: Query 11 Could Not Find Hash Cache For Join ID
Key: PHOENIX-3317
URL: https://issues.apache.org/jira/browse/PHOENIX-3317
Project: Phoenix
it down to a particular query that's causing the issue?
>
> Thanks,
> James
>
> On Thu, Aug 25, 2016 at 6:49 AM, John Leach <jle...@splicemachine.com
> <mailto:jle...@splicemachine.com>> wrote:
> Can anyone explain why the client would be burning so much CPU and m
Can anyone explain why the client would be burning so much CPU and memory if
the result is a single row?
I suspect we configured something wrong on Phoenix but we are having a hard
time figuring it out.
Thanks in advance.
Regards,
John
> On Aug 24, 2016, at 9:54 AM, Aaron Molitor
t offer significantly better performance for large datasets.
>
> On Tue, Aug 23, 2016 at 2:17 PM, John Leach <jle...@splicemachine.com>
> wrote:
>
>> So to load a TB of data would take around 2 days? Does that seem right to
>> you?
>>
>> Regards,
&g
hink its time would be too off from loading
> using multiple clients.
>
>
> On Tue, Aug 23, 2016 at 12:49 PM, John Leach <jle...@splicemachine.com>
> wrote:
>
>> Mujtaba,
>>
>> Not following the import process.
>>
>> The 5 parallel psql clients
0 group by l_returnflag, l_linestatus
> order by l_returnflag, l_linestatus;
> 4 row selected (*185.2** seconds*)
>
> *Data*
> do curl -O http://static.druid.io/data/benchmarks/tpch/100/lineitem.tbl.$i.gz
> ; done
>
>
>
> On Mon, Aug 22, 2016 at 7:48 AM, John Leach
It looks like you guys already have most of the TPCH queries running based on
Enis’s talk in Ireland this year. Very cool.
(Slide 20: Phoenix can execute most of the TPC-H queries!)
Regards,
John Leach
> On Aug 19, 2016, at 8:28 PM, Nick Dimiduk <ndimi...@gmail.com> wrote:
>
, would you be willing to attach your key xml
files (hbase-site.xml) so that we are testing phoenix in the best light?
Mujtaba would you mind sharing your schema and any indexes that are
appropriate?
We have a few copies of the TPCH data floating around but I appreciate the link.
Thanks,
John
15 matches
Mail list logo
