Interpretation of rows in Phoenix SYSTEM.CATALOG - apache-phoenix

When I create a Phoenix table there are two extra rows in SYSTEM.CATALOG. These are the first and the second rows in the output of SELECT * FROM SYSTEM.CATALOG ...... below. Can someone please help me understand what these two rows signify?
The third and fourth rows in the output of SELECT * FROM SYSTEM.CATALOG ...... below are easily relatable to the CREATE TABLE statement. Therefore, they look fine.
0: jdbc:phoenix:t40aw2.gaq> CREATE TABLE C5 (company_id INTEGER PRIMARY KEY, name VARCHAR(225));
No rows affected (4.618 seconds)
0: jdbc:phoenix:t40aw2.gaq> select * from C5;
+-------------+-------+
| COMPANY_ID | NAME |
+-------------+-------+
+-------------+-------+
No rows selected (0.085 seconds)
0: jdbc:phoenix:t40aw2.gaq> SELECT * FROM SYSTEM.CATALOG WHERE TABLE_NAME='C5';
+------------+--------------+-------------+--------------+----------------+----------------+-------------+----------+---------------+---------------+------------------+--------------+----+
| TENANT_ID | TABLE_SCHEM | TABLE_NAME | COLUMN_NAME | COLUMN_FAMILY | TABLE_SEQ_NUM | TABLE_TYPE | PK_NAME | COLUMN_COUNT | SALT_BUCKETS | DATA_TABLE_NAME | INDEX_STATE | IM |
+------------+--------------+-------------+--------------+----------------+----------------+-------------+----------+---------------+---------------+------------------+--------------+----+
| | | C5 | | | 0 | u | | 2 | null | | | fa |
| | | C5 | | 0 | null | | | null | null | | | |
| | | C5 | COMPANY_ID | | null | | | null | null | | | |
| | | C5 | NAME | 0 | null | | | null | null | | | |
+------------+--------------+-------------+--------------+----------------+----------------+-------------+----------+---------------+---------------+------------------+--------------+----+
4 rows selected (0.557 seconds)
0: jdbc:phoenix:t40aw2.gaq>
The Phoenix version I am using is: 4.1.8.29
Kindly note that no other operations where done on the table other than the 3 listed above, namely, create table, select * from the table, and select * from system.catalog where TABLE_NAME=the concerned table name.

Related

How to convert row into column in PostgreSQL of below table

I was trying to convert the trace table to resulted table in postgress. I have hug data in the table.
I have table with name : Trace
entity_id | ts | key | bool_v | dbl_v | str_v | long_v |
---------------------------------------------------------------------------------------------------------------
1ea815c48c5ac30bca403a1010b09f1 | 1593934026155 | temperature | | | | 45 |
1ea815c48c5ac30bca403a1010b09f1 | 1593934026155 | operation | | | Normal | |
1ea815c48c5ac30bca403a1010b09f1 | 1593934026155 | period | | | | 6968 |
1ea815c48c5ac30bca403a1010b09f1 | 1593933202984 | temperature | | | | 44 |
1ea815c48c5ac30bca403a1010b09f1 | 1593933202984 | operation | | | Reverse | |
1ea815c48c5ac30bca403a1010b09f1 | 1593933202984 | period | | | | 3535 |
Trace Table
convert the above table into following table in PostgreSQL
Output Table: Result
entity_id | ts | temperature | operation | period |
----------------------------------------------------------------------------------------|
1ea815c48c5ac30bca403a1010b09f1 | 1593934026155 | 45 | Normal | 6968 |
1ea815c48c5ac30bca403a1010b09f1 | 1593933202984 | 44 | Reverse | 3535 |
Result Table

Have you tried this yet?
select entity_id, ts,
max(long_v) filter (where key = 'temperature') as temperature,
max(str_v) filter (where key = 'operation') as operation,
max(long_v) filter (where key = 'period') as period
from trace
group by entity_id, ts;

Replace null by negative id number in not consecutive rows in hive

I have this table in my database:
| id | desc |
|-------------|
| 1 | A |
| 2 | B |
| NULL | C |
| 3 | D |
| NULL | D |
| NULL | E |
| 4 | F |
---------------
And I want to transform this table into a table that replace nulls by consecutive negative ids:
| id | desc |
|-------------|
| 1 | A |
| 2 | B |
| -1 | C |
| 3 | D |
| -2 | D |
| -3 | E |
| 4 | F |
---------------
Anyone knows how can I do this in hive?

Below approach works
select coalesce(id,concat('-',ROW_NUMBER() OVER (partition by id))) as id,desc from database_name.table_name;

PostgreSQL crosstab doesn't work as desired

In this example, I expect the resulting pivot table to have values for 4 columns, but instead there's only values for 2.
It should've returned something like this:
| time | trace1 | trace2 | trace3 | trace4 |
| -----------------------------------------|
| t | v | v | v | v |
| t | v | v | v | null |
| t | null | v | v | v |
| t | v | v | null | v |
| t | v | null | v | v |
|------------------------------------------|
but I got this instead:
| time | trace1 | trace2 | trace3 | trace4 |
| -----------------------------------------|
| t | v | v | null | null |
| t | v | v | null | null |
| t | v | v | null | null |
| t | v | null | null | null |
| t | v | null | null | null |
|------------------------------------------|
Even worse, if I remove
order by unixdatetime
, everything will be smashed into only 1 column as below:
| time | trace1 | trace2 | trace3 | trace4 |
| -----------------------------------------|
| t | v | null | null | null |
| t | v | null | null | null |
| t | v | null | null | null |
| t | v | null | null | null |
| t | v | null | null | null |
|------------------------------------------|
Here's the code:
select *
from crosstab(
$$
select
unixdatetime,
gaugesummaryid,
value::double precision
from
(values
(1546300800,187923,1.5),
(1546387200,187923,1.5),
(1546473600,187923,1.5),
(1546560000,187923,1.75),
(1546646400,187923,1.75),
(1546732800,187923,1.75),
(1546819200,187923,1.75),
(1546905600,187923,1.5),
(1546992000,187923,1.5),
(1547078400,187923,1.5),
(1547164800,187923,1.5),
(1547337600,187924,200),
(1547424000,187924,200),
(1547510400,187924,200),
(1547596800,187924,200),
(1547683200,187924,200),
(1547769600,187924,200),
(1547856000,187924,200),
(1547942400,187924,200),
(1548028800,187924,200),
(1548115200,187924,200),
(1548201600,187924,200),
(1548288000,187924,200),
(1546300800,187926,120),
(1546387200,187926,120),
(1546473600,187926,120),
(1546560000,187926,110),
(1546646400,187926,110),
(1546732800,187926,110),
(1546819200,187926,110),
(1546905600,187926,115),
(1546992000,187926,115),
(1547078400,187926,115),
(1547942400,187927,100),
(1548028800,187927,100),
(1548115200,187927,100),
(1548201600,187927,100),
(1548288000,187927,100)
) as t (unixdatetime, gaugesummaryid, value)
order by unixdatetime
$$
) as final_result (
unixdatetime int,
trace1 double precision,
trace2 double precision,
trace3 double precision,
trace4 double precision
);
Here's the link in case you'd like to play around:
https://dbfiddle.uk/?rdbms=postgres_11&fiddle=2c4f6098fb89b78898ba1bf6afa7f439
How to get the desired result?

I would recommend you to use filter (where ...) clause instead of a pivot table.
select
unixdatetime,
min(value) filter (where gaugesummaryid = 187923) as trace_1,
min(value) filter (where gaugesummaryid = 187924) as trace_2,
min(value) filter (where gaugesummaryid = 187926) as trace_3,
min(value) filter (where gaugesummaryid = 187927) as trace_4
from table
group by 1;
Note, that you have to use an aggregate function to be able to use the clause. In your case, it does not matter if you use min, max, avg or sum.

Use the 2-argument form of the crosstab function:
SELECT *
FROM crosstab(
$$
SELECT
unixdatetime,
gaugesummaryid,
value::double precision
FROM test
ORDER BY unixdatetime
$$
, 'SELECT DISTINCT gaugesummaryid FROM test ORDER BY 1 LIMIT 4'
) as final_result (
unixdatetime int,
trace1 double precision,
trace2 double precision,
trace3 double precision,
trace4 double precision
)
yields
| unixdatetime | trace1 | trace2 | trace3 | trace4 |
|--------------+--------+--------+--------+--------|
| 1546300800 | 1.5 | | 120 | |
| 1546387200 | 1.5 | | 120 | |
| 1546473600 | 1.5 | | 120 | |
| 1546560000 | 1.75 | | 110 | |
| 1546646400 | 1.75 | | 110 | |
| 1546732800 | 1.75 | | 110 | |
| 1546819200 | 1.75 | | 110 | |
| 1546905600 | 1.5 | | 115 | |
| 1546992000 | 1.5 | | 115 | |
| 1547078400 | 1.5 | | 115 | |
| 1547164800 | 1.5 | | | |
| 1547337600 | | 200 | | |
| 1547424000 | | 200 | | |
| 1547510400 | | 200 | | |
| 1547596800 | | 200 | | |
| 1547683200 | | 200 | | |
| 1547769600 | | 200 | | |
| 1547856000 | | 200 | | |
| 1547942400 | | 200 | | 100 |
| 1548028800 | | 200 | | 100 |
| 1548115200 | | 200 | | 100 |
| 1548201600 | | 200 | | 100 |
| 1548288000 | | 200 | | 100 |
Using this setup:
DROP TABLE IF EXISTS test;
CREATE TABLE test (
unixdatetime bigint,
gaugesummaryid int,
value double precision
);
INSERT INTO test VALUES
(1546300800,187923,1.5),
(1546387200,187923,1.5),
(1546473600,187923,1.5),
(1546560000,187923,1.75),
(1546646400,187923,1.75),
(1546732800,187923,1.75),
(1546819200,187923,1.75),
(1546905600,187923,1.5),
(1546992000,187923,1.5),
(1547078400,187923,1.5),
(1547164800,187923,1.5),
(1547337600,187924,200),
(1547424000,187924,200),
(1547510400,187924,200),
(1547596800,187924,200),
(1547683200,187924,200),
(1547769600,187924,200),
(1547856000,187924,200),
(1547942400,187924,200),
(1548028800,187924,200),
(1548115200,187924,200),
(1548201600,187924,200),
(1548288000,187924,200),
(1546300800,187926,120),
(1546387200,187926,120),
(1546473600,187926,120),
(1546560000,187926,110),
(1546646400,187926,110),
(1546732800,187926,110),
(1546819200,187926,110),
(1546905600,187926,115),
(1546992000,187926,115),
(1547078400,187926,115),
(1547942400,187927,100),
(1548028800,187927,100),
(1548115200,187927,100),
(1548201600,187927,100),
(1548288000,187927,100);

While some of the target values may be missing , you need the 2-argument form of crosstab() (like unutbu provided).
But it makes no sense to use a query producing unstable results as 2nd parameter. Use a VALUES expression (or similar) to provide a stable set of target columns in sync with the resulting column definition list. Like:
SELECT *
FROM crosstab(
$$
SELECT *
FROM (
VALUES
(bigint '1546300800', 187923, float8 '1.5')
, (1546387200,187923,1.5)
, (1546473600,187923,1.5)
-- , ...
, (1548288000,187927,100)
) t (unixdatetime, gaugesummaryid, value)
ORDER BY 1,2
$$
, 'VALUES (187923), (187924), (187926), (187927)' -- !!
) final_result (unixdatetime int
, trace1 float8
, trace2 float8
, trace3 float8
, trace4 float8);
db<>fiddle here
Detailed explanation:
PostgreSQL Crosstab Query
It would be nice to get results for a dynamic number of target columns from a single query. Alas, SQL does not work like that. There are various workarounds. See:
Execute a dynamic crosstab query

Filling gaps in postgresql

I have Actions table, which has rows ordered by time
| time | session |
|----------|-----------|
| 16:10:10 | session_1 |
| 16:13:05 | null |
| 16:16:43 | null |
| 16:23:12 | null |
| 16:24:01 | session_2 |
| 16:41:32 | null |
| 16:43:56 | session_3 |
| 16:51:22 | session_4 |
I want to write a select which will put previous meaningful value instead of nulls
How to get this result with postgresql?
| time | session |
|----------|-----------|
| 16:10:10 | session_1 |
| 16:13:05 | session_1 |
| 16:16:43 | session_1 |
| 16:23:12 | session_1 |
| 16:24:01 | session_2 |
| 16:41:32 | session_2 |
| 16:43:56 | session_3 |
| 16:51:22 | session_4 |

update Actions a
set session = (
select session
from Actions
where time = (
select max(time) from Actions b
where b.time < a.time and session is not null
)
) where session is null;
I tried this with 'time' as int and 'session' as int [easier to add data].
drop table Actions;
create table Actions (time int, session int);
insert into Actions values (1,10),(2,null),(3,null),(4,2),(5,null),(6,3),(7,4);
select * from Actions order by time;
update Actions a ...;
select * from Actions order by time;
EDIT
Response to your modified question.
select a1.time, a2.session
from Actions a1
inner join
Actions a2
on a2.time = (
select max(time) from Actions b
where b.time <= a1.time and session is not null
)

Optimization of Sybase 15.5 union query

im having trouble trying to optimize the following query on Sybase 15.5. Does anyone know how could i improve it. Each one of the tables used there have about 30 million rows each. I tried my best to optimize it but still taking lot of time(1.5 hours).
create table #tmp1( f_id smallint, a_date smalldatetime )
create table #tmp2( f_id smallint, a_date smalldatetime )
insert #tmp1
select f_id, a_date = max( a_date )
FROM audit_table
WHERE i_date = #pIDate
group by f_id
insert #tmp2
select f_id , a_date = max( a_date )
FROM n_audit_table
WHERE i_date = #pIDate
group by f_id
create table #tmp(
t_account varchar(32) not null,
t_id varchar(32) not null,
product varchar(64) null
)
insert into #tmp
select t_account,t_id, product
FROM audit_table nt, #tmp1 a
WHERE i_date = #pIDate
and nt.a_date = a.a_date
and nt.f_id = a.f_id
union
select t_account,t_id, product
FROM n_audit_table t, #tmp2 a
WHERE t.item_date = #pIDate
and t.a_date = a.a_date
and t.f_id = a.f_id
Both the tables having indexes on i_date, a_date, f_id. Please find below showplan where it is long time.
QUERY PLAN FOR STATEMENT 2 (at line 24).
Optimized using Serial Mode
STEP 1
The type of query is INSERT.
10 operator(s) under root
|ROOT:EMIT Operator (VA = 10)
|
| |INSERT Operator (VA = 9)
| | The update mode is direct.
| |
| | |HASH UNION Operator (VA = 8) has 2 children.
| | | Using Worktable1 for internal storage.
| | | Key Count: 3
| | |
| | | |NESTED LOOP JOIN Operator (VA = 3) (Join Type: Inner Join)
| | | |
| | | | |SCAN Operator (VA = 0)
| | | | | FROM TABLE
| | | | | #tmp1
| | | | | a
| | | | | Table Scan.
| | | | | Forward Scan.
| | | | | Positioning at start of table.
| | | | | Using I/O Size 2 Kbytes for data pages.
| | | | | With LRU Buffer Replacement Strategy for data pages.
| | | |
| | | | |RESTRICT Operator (VA = 2)(5)(0)(0)(0)(0)
| | | | |
| | | | | |SCAN Operator (VA = 1)
| | | | | | FROM TABLE
| | | | | | audit_table
| | | | | | nt
| | | | | | Index : IX_audit_table
| | | | | | Forward Scan.
| | | | | | Positioning by key.
| | | | | | Keys are:
| | | | | | i_date ASC
| | | | | | a_date ASC
| | | | | | Using I/O Size 2 Kbytes for index leaf pages.
| | | | | | With LRU Buffer Replacement Strategy for index leaf pages.
| | | | | | Using I/O Size 2 Kbytes for data pages.
| | | | | | With LRU Buffer Replacement Strategy for data pages.
| | |
| | | |NESTED LOOP JOIN Operator (VA = 7) (Join Type: Inner Join)
| | | |
| | | | |SCAN Operator (VA = 4)
| | | | | FROM TABLE
| | | | | #tmp2
| | | | | a
| | | | | Table Scan.
| | | | | Forward Scan.
| | | | | Positioning at start of table.
| | | | | Using I/O Size 2 Kbytes for data pages.
| | | | | With LRU Buffer Replacement Strategy for data pages.
| | | |
| | | | |RESTRICT Operator (VA = 6)(5)(0)(0)(0)(0)
| | | | |
| | | | | |SCAN Operator (VA = 5)
| | | | | | FROM TABLE
| | | | | | n_audit_table
| | | | | | t
| | | | | | Index : IX_n_audit_table
| | | | | | Forward Scan.
| | | | | | Positioning by key.
| | | | | | Keys are:
| | | | | | i_date ASC
| | | | | | a_date ASC
| | | | | | Using I/O Size 2 Kbytes for index leaf pages.
| | | | | | With LRU Buffer Replacement Strategy for index leaf pages.
| | | | | | Using I/O Size 2 Kbytes for data pages.
| | | | | | With LRU Buffer Replacement Strategy for data pages.
| |
| | TO TABLE
| | #tmp
| | Using I/O Size 2 Kbytes for data pages.
Total estimated I/O cost for statement 2 (at line 24): 29322945.

I doubt its a union issue. Queries are more probable troublemaker.
I suppose you should start from adding indexes on your temp tables:
create table #tmp1( f_id smallint, a_date smalldatetime )
Create clustered index IX1Temp on #tmp1(f_id )
Create clustered index IX2Temp on #tmp1(a_date )
...
Also, I see not much sense in #tmp1, #tmp2 the way you use them. You could call CTE instead. Also. I would recommend you to try PARTITION BY instead GROUP BY statement.

According to the query execution plan, the problem is the table scans on the temporary tables.
Please get the execution plan for the following query:
insert into #tmp
select t_account,t_id, product
FROM
audit_table nt,
(
select f_id, a_date = max(a_date)
FROM audit_table
WHERE i_date = #pIDate
group by f_id
) a
WHERE
i_date = #pIDate
and nt.a_date = a.a_date
and nt.f_id = a.f_id
union
select t_account,t_id, product
FROM
n_audit_table t,
(
select f_id , a_date = max( a_date )
FROM n_audit_table
WHERE i_date = #pIDate
group by f_id
) a
WHERE
t.item_date = #pIDate
and t.a_date = a.a_date
and t.f_id = a.f_id

How many rows end up in each of the temporary tables?
Looks like the temporary tables could be replaced by using HAVING, I would need to test it, it is always complicated when your group by is on a single column and you require more columns in the output.
Try running this statement with SET STATISTICS PLANCOST ON and SET STATISTICS IO ON as that would give a good idea of the number of pages that are scanned and if Sybase is going wrong somewhere while optimising the query.