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

Reported by fursten on 2012-08-13
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Percona Toolkit
Undecided
Unassigned

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.

fursten (msv-kth) wrote :
description: updated
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
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
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.

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

Other bug subscribers