Hi,
You don't mention what kind of task it is queued for, or perhaps it's even an action? Or the IdM version for that matter. I'm not sure how changing the views would change anything though.
In case it's a task (ordered, condt., switch etc) the dispatcher has for the latest versions been using the views mxpv_grouptasks_ordered/switch/conditional which already have 1000 row limiters in them.
If it's an action then the runtime should not be much affected by the size or really care how many are in the mxprov_entries view. It might take a few seconds to get the entire list og 60.000 rows if it doesn't add it's own limitation in addition to the action/repid filter. If they're all for the same actionid/repository combination it will just works through it one entry at a time untill it's done and each entry is enclosed in its own transaction so at this point there would be no effect of having a top 1000 or not It's also not possible to split up the queue action/repository combination between multiple runtimes either.
Br,
Per Christian
