R is single-threaded; why use dbPool?

Perhaps a silly question, but someone recently asked me about pool and I found myself without a good answer.

For a Shiny app that deals with multi-statement SQL transactions I completely understand the value of the pool package.

For apps that have -- for sake of argument -- only single-statement (or encapsulated) transactions, however, what're some good examples of when pool is useful? I ask specifically in the context of R being single-threaded, so unless a connection needs to be 'maintained' across expressions in a Shiny session (e.g. the transaction use case), only a single DBI expression will be evaluated at any given time, and thus a single connection should suffice, no?

(This also excludes parallel-procession approaches, which likely can't share connections anyhow due to process-forking or remote machines breaking the driver.)

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.