Option --where is missing from pt-online-schema-change

Bug #1036311 reported by fursten
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Percona Toolkit moved to https://jira.percona.com/projects/PT

Bug Description

When massaging a table I often want to restrict the content at the same time as I change the schema. For that a --where option on pt-online-schema-change would come in handy.

Since NibbleIterator already supports --where I think the only needed change would be to add the documentation (since the allowed options are parsed from the documentation). It works for me at least.

Revision history for this message
fursten (msv-kth) wrote :
description: updated
Revision history for this message
Daniel Nichter (daniel-nichter) wrote :

I can't recall off the top of my head, but I think there's a reason why we didn't include --where in the tool. It might be related to the triggers which won't respect --where. I'll leave this bug open while I think about this more.

tags: added: pt-online-schema-change standard-options
Changed in percona-toolkit:
status: New → Triaged
Revision history for this message
Daniel Nichter (daniel-nichter) wrote :

Since this isn't a bug, I've created https://blueprints.launchpad.net/percona-toolkit/+spec/pt-osc-where instead.

Changed in percona-toolkit:
status: Triaged → Invalid
Revision history for this message
Nathan Johnson (nathanejohnson) wrote :

I have added a potential solution to the issue with the triggers not respecting the where clause. I've attached the code to the blueprint that was created above.

The way I see it, there are three ways to deal with it:

1) don't deal with it, warn the user of the potential issues.

2) allow the user to specify a conditional that will be evaluated to determine whether changed rows are reflected in the temporary table. This would require the user to reference column names by the NEW and OLD aliases, as with all mysql triggers.

3) parse the where clause and try to determine which columns are being referenced, automatically / intelligently try to determine appropriate conditions to check in the triggers.

I have linked an implementation of #2. #3 would be kind of neat, but it would be difficult to implement correctly. #1 is obviously the easiest.

Revision history for this message
Nathan Johnson (nathanejohnson) wrote :
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-1012

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

Other bug subscribers