Request tag(per-transaction vs. per-query?)

[apstndb]

Currently, spanner-cli supports per-transaction tag and it is used as the request tag of all queries in the transaction.
#128

Users can be confused by the behavior that multiple queries with the same request tag string are grouped into a single row.

https://cloud.google.com/spanner/docs/introspection/troubleshooting-with-tags?hl=en#things_to_note

When you assign a REQUEST_TAG, statistics for multiple queries that have the same tag string are grouped in a single row in query statistics table. Only the text of one of those queries is shown in the TEXT field.

Possible actions:

a. Add a note to multiple queries with the same tag in the "Transaction Tags and Request Tags" section of the README
b. Add per-request request tag syntax with/without the explicit transaction

Related discussion: #129 (comment) (We are also not familiar with the behavior)

[takabow]

I confirmed that using the same request tag for different SQLs in a single transaction results in all the different SQLs being grouped together on the query stats and causing only a single SQL to be listed.

Let me confirm internally whether this behavior is the expected behavior.

[apstndb]

I think this behavior is usable when users want to group some logically-equivalent dynamic queries but it surprises users who want to group different queries by the tag loosely.

[takabow]

I apologize for not replying for so long. I have confirmed with the development team that grouping by a request tag is the intended behavior. It was also clarified in the documentation of query statistics.

https://cloud.google.com/spanner/docs/introspection/query-statistics#table_schema

Statistics for multiple queries that have the same tag string are grouped in a single row with the REQUEST_TAG matching that tag string.

The hash of the REQUEST_TAG value if present; Otherwise, the hash of the TEXT value.

[takabow]

I can't come up with a way to handle request tags in spanner-cli, but I have two simple ideas right now.

1. stop supporting request tags in spanner-cli
2. request tag = transaction tag + sequential number

Any ideas?

[yfuruyama]

Considering that users can't put a request tag on individual statement with spanner-cli, I think 2. request tag = transaction tag + sequential number might be a reasonable choice for now.

[apstndb]

I think 1. stop supporting request tags in spanner-cli is not bad because it won't surprise users
but if users want to filter spanner-cli-originated queries, spanner-cli should set request tags.

IMO, 2. request tag = transaction tag + sequential number is non-obvious behavior so it will need some documentation.

[takabow]

I just came up with an idea, how about request_tag = transaction_tag + SQL ?
The following image is a result of query stats from Query Insights.
In this example, I used tag1 as transaction_tag, and the tag added to request_tag as prefix.

if s.InReadWriteTransaction() {
    opts.RequestTag = s.tc.tag + ": " + stmt.SQL
    iter := s.tc.rwTxn.QueryWithOptions(ctx, stmt, opts)

[yfuruyama]

Request tag has maximum limit of the character length, that is 50 for now, so it's likely that moderate number of SQL queries will be truncated. That could confuse users if they're not aware of that limitation.

[yfuruyama]

IMO, 2. request tag = transaction tag + sequential number is non-obvious behavior so it will need some documentation.

Yeah this is not obvious, but my opinion is it's better than providing nothing. If we stop populating request tags, users can't correlate the transaction and the queries inside the transaction.

[takabow]

Thanks for pointing this out! As you mentioned, tag with a long sql text were truncated.

I am using spanner-cli to examine transactions and would like to correlate each query listed in the query stats with which transaction it was issued from. Unfortunately, the current query insights only shows the SQL text or the request tag. So, it would be useful to embed the transaction tag and each SQL text to request tags, even if only partially.

[yfuruyama]

Hmm that's a tough situation... but I thought that it might be useful to have a partial SQL text in a request tag rather than putting an unclear suffix like tag-1 or tag-2.

+1 for adding SQL text.

[takabow]

request tag = transaction tag + SQL text (partial)

@apstndb Would you give me your thoughts on this?

[apstndb]

Unfortunately, the current query insights only shows the SQL text or the request tag.

Because of this, I have always thought that Query Insights is not a good tool for examining the details of a query, and I was more concerned with how it is represented in Query Stats. I am hopeful that Query Insights will be fixed.

My personal experience is that the important part of the query is often not in the first 50 characters, but in the WHERE clause, GROUP BY clause, etc.
Therefore, if the second half of the query is truncated, there is a concern that completely different queries will be grouped together.

[apstndb]

It is possible to implement an option to switch tag naming.

[takabow]

Therefore, if the second half of the query is truncated, there is a concern that completely different queries will be grouped together.

Right, this is an important point of view.

It is possible to implement an option to switch tag naming.

It's a good idea.

For example, by default, auto tagging of request tags is disabled, and if the flag is enabled,
then reqeust_tag = transaction_tag + sequence + SQL_text