There is no gross difference in querying a queue or a roster. Each is a table and the issue in querying them will be based on the number of items needed to be reviewed by the database, the effort in deconstructing what needs to be returned and the number of objects that are returned.

Some general rules.

1. A roster is used to find WORK. It represents work that could be in any number of different queues. Otherwise you'd have to scan each queue to find work. Think of it as a lookup to your work regardless of queue.
2. A queue is used to separate similar work for similar actions. Work is processed from a queue and can be filtered. It is rare to look for work via a queue as a roster is more efficient.
3. To process work you either know the queue its in (inbox style application), or look it up in the roster and then process it.
4. You always return queue ELEMENTS or roster elements in a query where you don't know how many items are returned. This is simply a return of columns in the table.
5. You only return work objects, step elements or instruction elements when you have a small number or a known number of items to process. Typically, BROWSE for queue elements, lock an item, get a step element, process the item, dispatch, and then back to browse.
6. Getting data elements via work object, step element or instruction elements requires more processing by the process engine as the data isn't in the columns of the table but is in the BLOB data. For a large number of objects this is a performance impact, but understand the impact, and if necessary do it. Do not do it for an unknown number of returned results.
7. Make sure you expose business data on the queue for filtering work and on the roster to find it. The same data can be exposed on each. This puts the data in a column on the roster or the queue and means you can retrieve the roster element of queue element without a great overhead in the database or process engine.
8. Make sure you build indices on the data elements that are exposed so that table scans aren't needed to retrieve your data.

Your process design will not be impacted by the query you build. You build the query based on the process requirements, the process design and the configuration that is created for the queues and rosters that are needed to support your query.

There is no gross difference in querying a queue or a roster. Each is a table and the issue in querying them will be based on the number of items needed to be reviewed by the database, the effort in deconstructing what needs to be returned and the number of objects that are returned.

Some general rules.

Your process design will not be impacted by the query you build. You build the query based on the process requirements, the process design and the configuration that is created for the queues and rosters that are needed to support your query.