The test database is only created at the start of the test run, not at the start of every test.

We need to have a guaranteed clean test environment for each test run, and the easiest way to do this is to create a new test database each time.

If you think you have a faster way to run the tests, the onus is on you to prove it! You can do this by providing a patch (either a fully worked patch, or a proof-of-concept patch) with timings showing what the speedup would be, and what unexpected consequences of your approach exist (if any).

There can be reasons to use an existing "database" -- for example, on PostgreSQL and Oracle this allows one to control the tablespace to be used by the tests. In fact, on Oracle this is already supported (Oracle does not have databases in the sense of PostgreSQL, and the relevant settings actually refer to tablespaces), and I think supporting it on Postgres too is a good idea.

However, even under these circumstances, it is usually desirable to use a new "schema" in the database; and it is the generation of objects in this schema that takes most of the time in creating and dropping test databases. So, testing speed should not change significantly.

On MySQL, "schema" is synonymous with "database", and the concept of "tablespace" only exists for specific (cluster) storage types, so this doesn't make much sense anyway.