-
Notifications
You must be signed in to change notification settings - Fork 109
Add progress for each partition in SHOW PROCESSLIST #855
Conversation
Signed-off-by: Carlos Martín <[email protected]>
Overall the functionality and the implementation look good to me, but I just have one doubt: what is the expected way of using this in a client (i.e. gitbase)? I see ProcessTable having the callbacks, but the client is not supposed to touch ProcessTable at all. In fact, it's a node for internal use and the user should never have to even know it exists. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM after considering what @erizocosmico said.
gitbase doesn't need to change at all. All the progress is tracked with the changes in this PR, the callbacks are called by the There is one caveat I didn't mention. The name of the Partition is made from the For gitbase the implementation works as it is. But we might want to add type Partition interface {
Nameable
Key() []byte
} or leave the The first option is a breaking change for a feature that might not be too relevant for other users. The second one is not breaking, but will be completely missed and it's probably easier to just leave the code as it is now, and assume the WDYT? |
I think 2nd option might be best |
Signed-off-by: Carlos Martín <[email protected]>
Done in a385e34. |
This is a proposal to add some more information to the
SHOW PROCESSLIST
output.It adds a counter for each active partition. A partition gets removed from the list when it finishes.
This is how it looks:
The new output can be used to notice when for some reason a repository takes more time than others to finish.
Because there aren't totals, the counter of each partition cannot be used to get an estimate of the progress made. Right now its only function is to let the user know that the iterator is working.
I am concerned with the
onNext
function, because I'm not sure if updating the progress for every row will have an impact on performance. I'm working on testing this, but so fargitbase-regression
has been giving me unreliable times.If we removed
onNext
we could still benefit from having the name of the active partitions, maybe with a(?/?)
progress.Another generic improvement would be to have a way to get the total number of rows for a table. Maybe implementing a new interface. I didn't explore this possibility because as far as I know in gitbase we won't be able to use this. But it may be an interesting generic addition later for go-mysql-server itself.