pt-query-digest should have a --group-by option for 'transaction-fingerprint'

Bug #1178757 reported by Jay Janssen
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Toolkit moved to https://jira.percona.com/projects/PT
Invalid
Undecided
Unassigned

Bug Description

transaction_fingerprint would generate a signature by appending all the statements together with the same Innodb_trx_id. Stats for said transaction would need to be summarized from all individual statements (thinks like rows affected, etc.)

Revision history for this message
Daniel Nichter (daniel-nichter) wrote :

Jay, you can --group-by any attribute, so --group-by InnoDB_trx_id should do this. Can you confirm?

tags: added: pt-query-digest
Revision history for this message
Jay Janssen (jay-janssen) wrote :

Daniel,
  It does, but that gives me a list of unique transactions, one per individual transactions.. I want a grouping by unique transaction fingerprint so I can see stats on different types of transactions that are commonly run on a given workload.

Revision history for this message
Daniel Nichter (daniel-nichter) wrote :

Jay, define "transaction fingerprint"? I think we talked about this earlier. Iirc, there's probably no way to isolate transactions since is:

BEGIN
query 1
COMMIT

and

BEGIN
query 1
query 2
COMMIT

logically the same fingerprint? It would seem like no, but maybe higher up in the app it really is the same trx and query2 is due to some condition in the app.

Revision history for this message
Jay Janssen (jay-janssen) wrote : Re: [Bug 1178757] pt-query-digest should have a --group-by option for 'transaction-fingerprint'

On Aug 2, 2013, at 2:24 PM, Daniel Nichter <email address hidden> wrote:

> BEGIN
> query 1
> COMMIT
>
> and
>
> BEGIN
> query 1
> query 2
> COMMIT
>
> logically the same fingerprint? It would seem like no, but maybe higher
> up in the app it really is the same trx and query2 is due to some
> condition in the app.

I'll grant this can get complex. For my purposes, the low hanging fruit would be simply all the queries concatenated together and run through the standard fingerprinting function for now.

I'd wager most transactions would have only a few variations in app logic, so if those show up as separate fingerprints, fine.

Jay Janssen, MySQL Consulting Lead, Percona
http://about.me/jay.janssen

Revision history for this message
Daniel Nichter (daniel-nichter) wrote :

Ok, I see. So trx-1 (transaction fingerprint) is made from the fingerprints query-1 and query-2. Then we show metrics for trx-1 which is really the aggregation of query-1 and query-2 metrics?

Revision history for this message
Daniel Nichter (daniel-nichter) wrote :
Changed in percona-toolkit:
status: New → Invalid
Revision history for this message
Jay Janssen (jay-janssen) wrote :

That was my thought, yes.

On Aug 2, 2013, at 3:53 PM, Daniel Nichter <email address hidden> wrote:

> Ok, I see. So trx-1 (transaction fingerprint) is made from the
> fingerprints query-1 and query-2. Then we show metrics for trx-1 which
> is really the aggregation of query-1 and query-2 metrics?

Jay Janssen, MySQL Consulting Lead, Percona
http://about.me/jay.janssen

Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PT-1111

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers