[
https://issues.apache.org/jira/browse/PHOENIX-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14323151#comment-14323151
]
James Taylor commented on PHOENIX-1115:
---------------------------------------
Thanks for the patch, [~rajeshbabu]. Here's some feedback:
- Rather than surfacing this through an ALTER SESSION command, how about a
TRACE ON/OFF command. It'll be similar in terms of implementation, but instead
of treating this as a mutate statement, treat it as a query. It'll return one
row with a single TRACE_ID BIGINT column value. That way, when invoked from
sqlline, it'll print out the trace ID (as if it was a SELECT statement), and
when invoked programmatically (i.e. hopefully someone will build a tool for
this), then you could do a resultSet.getLong(1) to get the top level trace ID.
The other advantage of having a specific command for it is that we can add
various options and it'll fail if the user gets them wrong.
- Rather than write some relatively hacky print out code (which is after all
just a nearly unusable way of visualizing the trace info), we can surface this
similar to the way MySQL does: allow people to query the SYSTEM.TRACE table
directly (or provide a simple VIEW on top named
INFORMATION_SCHEMA.OPTIMIZER_TRACE which might be even better, though fixing
PHOENIX-1507 might be a prereq). That way, we don't have to support other
tracing output options, as the user can take advantage of sqlline being able to
output query results in CSV format (if they want to export the trace
information for visualization in Excel or some other tool, for example). On our
website, we'll document a few canned queries to get the user started:
{code}
SELECT description, hostname, start_time, end_time - start_time duration
FROM SYSTEM.TRACING
WHERE trace_id = <your trace id>
ORDER BY start_time;
-- Select trace ID of last SQL statement
-- TODO: Verify this
SELECT trace_id, description
FROM SYSTEM.TRACING
WHERE parent_id = <your trace id>
ORDER BY trace_id DESC
LIMIT 1;
-- Select 10 longest running operations for a given trace
-- TODO: Try grouping by SPAN_ID instead and select MAX(description)
-- as it's likely the same and will be more efficient.
SELECT hostname, description, MAX(start_time - end_time)
FROM SYSTEM.TRACING
WHERE trace_id = <your trace id>
GROUP BY hostname, description
ORDER BY MAX(start_time - end_time)
LIMIT 10;
{code}
- Is the code below to group all batched Put mutations info a single span, and
if so, can we just always do this (but without the instanceof and check for
Sampler.ALWAYS), as there's no harm in doing this, right?
{code}
@@ -186,6 +194,7 @@ public class PhoenixStatement implements Statement,
SQLCloseable, org.apache.pho
private int maxRows;
private int fetchSize = -1;
private int queryTimeout;
+ private TraceScope trace = null;
public PhoenixStatement(PhoenixConnection connection) {
this.connection = connection;
@@ -267,6 +276,14 @@ public class PhoenixStatement implements Statement,
SQLCloseable, org.apache.pho
build().buildException();
}
try {
+ if (connection.isSqlTraceOn() && connection.getAutoCommit()
+ && connection.getSampler().equals(Sampler.ALWAYS)
+ && !(stmt instanceof AlterSessionStatement)) {
+ if(trace == null) {
+ TraceScope scope = Tracing.startNewSpan(connection,
"Executing mutation statement");
+ trace = scope;
+ }
+ }
return CallRunner
.run(
new CallRunner.CallableThrowable<Integer,
SQLException>() {
{code}
> Provide a SQL command to turn tracing on/off
> --------------------------------------------
>
> Key: PHOENIX-1115
> URL: https://issues.apache.org/jira/browse/PHOENIX-1115
> Project: Phoenix
> Issue Type: Sub-task
> Affects Versions: 5.0.0, 4.1
> Reporter: James Taylor
> Assignee: Rajeshbabu Chintaguntla
> Attachments: PHOENIX-1115.patch, PHOENIX-1115_v2.patch, Screen Shot
> 2014-11-21 at 3.41.41 PM.png, tracing_in_different_rdbms.pdf
>
>
> Provide a SQL command that turns tracing on and off. For example, Oracle has
> this:
> {code}
> ALTER SESSION SET sql_trace = true;
> ALTER SESSION SET sql_trace = false;
> {code}
> We might consider allowing the sampling rate to be set as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
