Hi,
It seems that the UPDATE_CACHE_FREQUENCY setting is ignored on tables with a
ROW_TIMESTAMP column set. This results in an RPC call to fetch the
SYSTEM.CATALOG table for every query to such a table and resulting hotspotting
on the node assigned the system catalog region.
I was wondering
.
-Original Message-
From: Josh Elser
Sent: June 10, 2019 10:44 AM
To: user@phoenix.apache.org
Subject: Re: Problem with ROW_TIMESTAMP
When you want to use Phoenix to query your data, you're going to have a much
better time if you also use Phoenix to load the data.
Unless you specifically know what
read and write your data.
On 6/7/19 1:31 PM, David Auclair wrote:
Hi,
I’m having a problem with ROW_TIMESTAMP not producing proper output:
Versions (Based on HDP 2.6.5):
HBase Shell = Version 1.1.2.2.6.5.1100-53 (assuming HBase is the same
version?)
Phoenix = phoenix-4.7.0.2.6.5.1100-53
Hi,
I'm having a problem with ROW_TIMESTAMP not producing proper output:
Versions (Based on HDP 2.6.5):
HBase Shell = Version 1.1.2.2.6.5.1100-53 (assuming HBase is the same version?)
Phoenix = phoenix-4.7.0.2.6.5.1100-53-client.jar
Phoenix Sqlline = 1.1.8
In the HBase shell, I create a table
; Thanks,
>> > James
>> >
>> > On Fri, Feb 2, 2018 at 9:05 AM, Alberto Bengoa
>>
>> > alberto@.com
>>
>> >
>> > wrote:
>> >
>> >> Hello Folks,
>> >>
>> >> I'm working on a project where we n
gt; > Sounds like you need PHOENIX-4552. If you agree, let's continue the
> > discussion over there.
> > Thanks,
> > James
> >
> > On Fri, Feb 2, 2018 at 9:05 AM, Alberto Bengoa
>
> > alberto@.com
>
> >
> > wrote:
> >
> >> Hello Folks,
I'm working on a project where we need to identify when a row was changed
>> (updated fields). I was wondering if ROW_TIMESTAMP would help me to reach
>> this goal.
>>
>> I created the test table bellow, and inserted some data:
>>
>> create table test(
>>
row was changed
> (updated fields). I was wondering if ROW_TIMESTAMP would help me to reach
> this goal.
>
> I created the test table bellow, and inserted some data:
>
> create table test(
> a integer not null,
> b integer,
> last_update date not null
> CONSTRAINT
Hello Folks,
I'm working on a project where we need to identify when a row was changed
(updated fields). I was wondering if ROW_TIMESTAMP would help me to reach
this goal.
I created the test table bellow, and inserted some data:
create table test(
a integer not null,
b integer
Hi Team,
I would like to store ROW_TIMESTAMP as TIMESTAMP in nanoseconds, what is
the best way to generate Timestamp with nanoseconds and when I query using
ROW_TIMESTAMP stored in nanoseconds do I loose the precision to
milliseconds.
Thanks
I'm encountering the following issue with Phoenix:
create table rtt (ts TIMESTAMP PRIMARY KEY ROW_TIMESTAMP);
select * from rtt where ts < now();
java.lang.NullPointerException
at
org.apache.phoenix.compile.ScanRanges.getAscTimeRange(ScanRanges.java:
> >>>
> >> On Tue, Feb 7, 2017 at 2:18 PM, Dhaval Modi <dh...@gmail.com>>
> >> wrote:>
> >>>
> >>> Hi Pedro,>
> >>>>
> >>> Upserted key are different. One key is for July month & other for>
> >>> January month
phoenix.apache.org%3E
>
>
> I also faced similar issue.
>
>
> Regards,
> Dhaval Modi
> dhavalmod...@gmail.com
>
> On 26 February 2017 at 10:34, NaHeon Kim <honey.and...@gmail.com> wrote:
>
>> Hi all,
>>
>> UPSERT into a table with ROW_TIMESTAMP co
and...@gmail.com> wrote:
> Hi all,
>
> UPSERT into a table with ROW_TIMESTAMP column is not possible.
> I'm using phoenix-4.8.0-hbase-1.1.
>
> Table Schema:
>
> create table my_table (
>obj_id varchar(20) not null,
>create_dt timestamp not null,
>ke
Hi all,
UPSERT into a table with ROW_TIMESTAMP column is not possible.
I'm using phoenix-4.8.0-hbase-1.1.
Table Schema:
create table my_table (
obj_id varchar(20) not null,
create_dt timestamp not null,
keyword varchar(100) not null,
count integer
constraint pk primary key
's weird. That column is PK and you've upserted twice
>>> the same key value so first one is inserted and second one is updated.
>>>
>>> Regards.
>>>
>>>
>>>
>>> On 7 Feb 2017 04:59, "Dhaval Modi" <dhavalmod...@gma
've upserted twice the
>> same key value so first one is inserted and second one is updated.
>>
>> Regards.
>>
>>
>>
>> On 7 Feb 2017 04:59, "Dhaval Modi" <dhavalmod...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>>
> I don't think it's weird. That column is PK and you've upserted twice the
> same key value so first one is inserted and second one is updated.
>
> Regards.
>
>
>
> On 7 Feb 2017 04:59, "Dhaval Modi" <dhavalmod...@gmail.com> wrote:
>
>> Hi All,
Hi.
I don't think it's weird. That column is PK and you've upserted twice the
same key value so first one is inserted and second one is updated.
Regards.
On 7 Feb 2017 04:59, "Dhaval Modi" <dhavalmod...@gmail.com> wrote:
> Hi All,
>
> I am facing abnormal scenarios
Hi All,
I am facing abnormal scenarios with ROW_TIMESTAMP.
I created table in Phoenix as below:
CREATE TABLE DUMMY(XXX_TS TIMESTAMP NOT NULL CONSTRAINT pk PRIMARY KEY
(XXX_TS ROW_TIMESTAMP))
where "XXX_TS" is used as ROW_TIMESTAMP.
Now, I am trying to add data:
upsert into DUMMY value
<mailto:user@phoenix.apache.org>>
Date: Wednesday, August 10, 2016 at 1:12 PM
To: "user@phoenix.apache.org<mailto:user@phoenix.apache.org>"
<user@phoenix.apache.org<mailto:user@phoenix.apache.org>>
Subject: Re: Problems with Phoenix bulk loader when using row_time
.apache.org>
> Date: Wednesday, August 10, 2016 at 12:05 AM
> To: "user@phoenix.apache.org" <user@phoenix.apache.org>
> Subject: Re: Problems with Phoenix bulk loader when using row_timestamp
> feature
>
> Ryan,
>
> Can you tell us what the explain plan says for the
We have a Phoenix table, all data was created by Phoenix SQL.
Normally, we use Phoenix SQL directly. But sometimes, we also need to
export data incrementally by data's created time.
Currently, we use HBase API directly by timestamps.
The new feature 'row_timestamp' seems to be more suitable
when I query
data from phoenix with ROW TIMESTAMP FILTER, it always got wrong result.
On Sat, Dec 12, 2015 at 2:34 AM, Samarth Jain <sama...@apache.org> wrote:
> Hi Roc,
>
> FWIW, looking at your schema, it doesn't look like you are using the
> ROW_TIMESTAMP feature. The constrain
Hi all
I try to use phoenix 4.6 to deal with time series data,
this is my table schema
create table log_data_46201512(
server_timestamp timestamp not null,
app_id varchar,
client_timestamp timestamp,
client_ip INTEGER not null,
cluster_id varchar,
host_id varchar,
device_uuid varchar,
url
Thanks for your reply.
In my test table, I used the row_timestamp feature and I lost ROW_TIMESTAMP
key word when I copied schema to this mail,
when I finished data load, I executed that query several times, and got
different cont,
it seemed that the result affected by where the data is, in hbase
Hi Roc,
FWIW, looking at your schema, it doesn't look like you are using the
ROW_TIMESTAMP feature. The constraint part of your DDL needs to be changed
like this:
CONSTRAINT my_pk PRIMARY KEY (
server_timestamp ROW_TIMESTAMP,
app_id, client_ip,
cluster_id,host_id,api
)
For the issue of getting
27 matches
Mail list logo
