You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@phoenix.apache.org by Me...@lamresearch.com on 2017/10/30 19:56:48 UTC

Particular column shows NA for certain queries, is populated for others

Hello all,

I am having a confusing problem when querying a Phoenix table via a JDBC connection (in R as well as client like Squirrel).  The table has five columns.  When I query the table like so:

select * from table1 where column1 = "A" and column2 = "B" and column3 = "C"

the query returns all five columns with "NA" as the value in the fifth column - a column I KNOW to be populated.  However, if I query:

select column5 from table1 where column1 = "A" and column2 = "B" and column3 = "C"

the query returns the populated column5.

The other odd detail - if I add a limit clause to the SELECT * query, be it limit 1 or limit 1000 (there are far less than 1000 records total in this table), column5 will populate.  Otherwise, NA.

Any insight or theories on this odd behavior would be greatly appreciated!

Thank you,

M.



RE: Particular column shows NA for certain queries, is populated for others

Posted by Me...@lamresearch.com.
Hello,

Thank you, yes it is, and indeed the rows are quite heavy.  I will try this fix, thank you.

Megan


From: sergey.soldatov@gmail.com [mailto:sergey.soldatov@gmail.com] On Behalf Of Sergey Soldatov
Sent: Monday, October 30, 2017 1:11 PM
To: user@phoenix.apache.org
Subject: Re: Particular column shows NA for certain queries, is populated for others

Does it reproducible only on large data sets? If so, then you possible hit PHOENIX-3112 bug. As a workaround, you may try to increase hbase.client.scanner.max.result.size<https://issues.apache.org/jira/browse/PHOENIX-3118> property to something big (100Mb for example).

Thanks,
Sergey

On Mon, Oct 30, 2017 at 12:56 PM, <Me...@lamresearch.com>> wrote:
Hello all,

I am having a confusing problem when querying a Phoenix table via a JDBC connection (in R as well as client like Squirrel).  The table has five columns.  When I query the table like so:

select * from table1 where column1 = “A” and column2 = “B” and column3 = “C”

the query returns all five columns with “NA” as the value in the fifth column – a column I KNOW to be populated.  However, if I query:

select column5 from table1 where column1 = “A” and column2 = “B” and column3 = “C”

the query returns the populated column5.

The other odd detail – if I add a limit clause to the SELECT * query, be it limit 1 or limit 1000 (there are far less than 1000 records total in this table), column5 will populate.  Otherwise, NA.

Any insight or theories on this odd behavior would be greatly appreciated!

Thank you,

M.




Re: Particular column shows NA for certain queries, is populated for others

Posted by Sergey Soldatov <se...@gmail.com>.
Does it reproducible only on large data sets? If so, then you possible
hit PHOENIX-3112 bug. As a workaround, you may try to increase
hbase.client.scanner.max.result.size
<https://issues.apache.org/jira/browse/PHOENIX-3118> property to something
big (100Mb for example).

Thanks,
Sergey

On Mon, Oct 30, 2017 at 12:56 PM, <Me...@lamresearch.com> wrote:

> Hello all,
>
>
>
> I am having a confusing problem when querying a Phoenix table via a JDBC
> connection (in R as well as client like Squirrel).  The table has five
> columns.  When I query the table like so:
>
>
>
> *select * from table1 where column1 = “A” and column2 = “B” and column3 =
> “C”*
>
>
>
> the query returns all five columns with “NA” as the value in the fifth
> column – a column I KNOW to be populated.  However, if I query:
>
>
>
> *select column5 from table1 where column1 = “A” and column2 = “B” and
> column3 = “C”*
>
>
>
> the query returns the populated column5.
>
>
>
> The other odd detail – if I add a limit clause to the SELECT * query, be
> it limit 1 or limit 1000 (there are far less than 1000 records total in
> this table), column5 will populate.  Otherwise, NA.
>
>
>
> Any insight or theories on this odd behavior would be greatly
> appreciated!
>
>
>
> Thank you,
>
>
>
> M.
>
>
>
>
>