I've read that using sub queries on large datasets has some effects on performance. Our tables have more than a million records.
Here you are using a union query and if you alias it, it is still not a sub query. However union queries can be inefficient for sorting/filtering/subsequent criteria as the indexing is not available. So better to include criteria and ordering in each union part.
The order of each union part can also make a difference - data from later selects appear at the top of the resulting dataset, not the bottom as you would expect. Not sure why or wether always consistent but suspect it might have something to do with the generated query plan - might be the simpler the select, the earlier it is processed. So try swapping the two selects around, might save the need for a sort
also a simple union will remove duplicates so you might be better using union all,
a sub query is one that is processed on each row of the recordset which is why they can be slow. Not always possible but can look at using an aliased query instead of a sub query either using non standard joins or as a Cartesian query