I think you should be able to use FieldComparator for the "large queue".
If your "large queue" is a list/array, then it has slots, and you just reference those slots when asking FieldComparator to compare.
The only difference from the FieldComparator's standpoint is you are doing far fewer compare calls as-you-go, then periodically you have a big burst of compares (the "selection algorithm", which should be implementable on FieldComparator) to find a new rough bottom.
But... have you thought about theoretical cost of "true pqueue" vs "approximate pqueue"? I think in the worst case, where results are returned in precisely reverse sort order, so that you always fully turnover the queue, is tricky.
Say your queue size is 10K, but you tolerate say 20 K until pruning. With worst case, every 10K hits you will have to re-select to dump the 10K worst. So cost is O(N * M), where M = queue size and N = total number of hits, though with a smallish 1/10K constant.
With true pqueue, every hit pays log(M) price, so total cost is O(N * log(M)).
But actually that 1/10K constant = 1/M, and so I think the approximate PQ works out to O(N) cost, which is in fact much cheaper. I think?