phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ankit Singhal (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-2715) Query Log
Date Sun, 08 Apr 2018 13:11:00 GMT


Ankit Singhal commented on PHOENIX-2715:

Thanks [~elserj] for testing it.

bq. I see the SYSTEM.LOG table was created, but the table is not getting propagated with any
information. Maybe it's related to just using sqlline? I've been waiting a bit to see if the
results are just delayed, and that doesn't seem to be the case. I can see that the QueryLogger
is created and then stopped before I get a prompt. Additionally, I can see that there is no
QueryLogger* thread running in the sqlline jvm
My bad, while porting patch for master , I moved disruptor from connection to connection query
services so that we will not create it for every connection, but close() was happening in
connection only, so the disruptor is getting shutdown for any connection close. I fixed it
in the latest patch. 

bq. maybe I need to enable request metrics for it to work?(QueryServices.COLLECT_REQUEST_LEVEL_METRICS)
this needs to be set if we need scan metrics to be logged.(SCAN_METRICS_JSON column)
SCAN_METRICS_JSON       [{"scan":{"loadColumnFamiliesOnDemand":null,"filter":"COLUMN_FAMILY
IS NULL","startRow":"\\x00\\x00SYSTEM.LOG\\x00\\x01","stopRow":"\\x00\\x00SYSTEM.LOG\\x01","batch":-1,"cacheBlocks":true,"totalColumns":7,"maxResultSize":2097152,"families":{"0":["COLUMN_SIZE","DATA_TYPE","KEY_SEQ","PK_NAME"]},"caching":2147483647,"maxVersions":1,"timeRange":[0,9223372036854775807]},

> Query Log
> ---------
>                 Key: PHOENIX-2715
>                 URL:
>             Project: Phoenix
>          Issue Type: New Feature
>            Reporter: Nick Dimiduk
>            Assignee: Ankit Singhal
>            Priority: Major
>         Attachments: PHOENIX-2715.patch, PHOENIX-2715_master.patch, PHOENIX-2715_master_V1.patch
> One useful feature of other database systems is the query log. It allows the DBA to review
the queries run, who's run them, time taken, &c. This serves both as an audit and also
as a source of "ground truth" for performance optimization. For instance, which columns should
be indexed. It may also serve as the foundation for automated performance recommendations/actions.
> What queries are being run is the first piece. Have this data tied into tracing results
and perhaps client-side metrics (PHOENIX-1819) becomes very useful.
> This might take the form of clients writing data to a new system table, but other implementation
suggestions are welcome.

This message was sent by Atlassian JIRA

View raw message