"Better" could have many meanings. This is a tricky question and the answer would require some assumptions. Anyway, I will throw in my 2 cents...
In your case, and index will not help. The optimizer will probably ignore it since you have 2 types only.
To execute the query on the server, you may consider 3 factors affecting the response speed:
Connection time - Can be addressed by having a large connection pool.
Query execution time - Can be addressed in many ways such as proper table design, creating good indexes, etc. But in this case, this won't help. Try not use SELECT * if you could and only get the columns required.
Communication time between the client and the server - Can be addressed by making the data transferred smaller when possible (overlaps with 2 also).
From the above, we can say that, to execute 2 separate queries, you will have to:
A - Do 2 connections from the client to the server.
B - Read the entire table 2 times, 1 for each query, since we assume the index will be ignored.
The network will handle any size of data in a linear fashion, and
The network can handle the transfer of the big data, and
The database server does not drop the connection in the middle (big risks) and
The application can hold the entire returned result set in memory,
The time required to read the data from disk is less than the time required to insert the data in a program structure such as an array.
Then, I guess filtering the data on the client would be faster from a performance stand-point, because you would use 1 database connection and 1 read of the table from disk by the database, the second read will be from the memory only.
The difference may not be felt unless the table is very large though.
Having said that, I would still try to let the database do the filtering and issue two separate queries. This is because this operation is commonly considered as one of its responsibilities. Also, in some cases, you can do parallel processing, where you run 1 query and start using the returned data while the other query is still executing.