Like all forms of persistent CGI handling, a mod_perl app handles many requests during its lifetime and can therefore simply keep a DBI-handle open all the time.   Sometimes this is the best way to handle it; it certainly is the simplest, e.g. if you have only one database that you need to connect to.

But otherwise, if you need connection pooling, you need to use any one of several available CPAN modules to do it.   (For example, DBIx::Connector.)   IMHO, these would probably come into play when there are several databases to which you need to maintain connections, some being used more frequently than others and/or some having a very high demand for connections.

If you are in this “very high demand” situation, then perhaps consider a client/server arrangement in which workers, instead of seeking the information themselves, post an asynchronous request for that information to another service process (or pool of the same).   A backlog in a queue of requests can be serviced in constant time regardless of the momentary length of the queue, whereas a backlog of “too many cooks in the kitchen” can result in suddenly-exponential performance degradation curves similar to that of virtual memory “thrashing.”   But, this is a fairly fundamental change in design philosophy, away from a tight-knit monolithic application to a loosely-coupled system of cooperating applications; not merely database connection pooling.

A less-intrusive notion is to introduce the idea of “a counting semaphore,” in which processes must acquire the semaphore before obtaining a connection or what-have-you and only n processes may simultaneously do so.   Like taking a number at the meat-counter in the grocery store.   Some, but not all, implementations of what they call “pooling” do that.