See "Performance Issues for Queue Tables" in pdf: "SQL Data Definition Language" for the database version you are looking at. Some statements re performance state:
The expected behavior for a queue table is that the producers of queue table rows are
working at approximately the same speed as their consumers: rows are consumed as
quickly as they are inserted into the table.
In other words, an application that would typically populate a queue table with millions of
rows before consuming any of them would not see any performance gain over using a
nonqueue table, so is not a good candidate for using the feature.
When the number of queue table rows on a single PE frequently exceeds the size of the
queue table cache, which is approximately 2,000 row entries per table or 20,000 row
entries per PE53, then the system must perform full-table scans more frequently to refresh
the cache. Such states also increase the likelihood of errors related to lock-oriented
transaction aborts and queue table cache overflow being returned to the requestor.