>>2744
Are we having the equivalent of a threadpool (or in Go's case I guess the green thread/goroutine equivalent) to read from sqlite, having multiple readers (as opposed to the previous scenario where all incoming requests were constrained by 1 reader).

It's probably just me because I've never used go before, but I found it a bit hard to follow what exactly is going on. Basically we implement the goroutine equivalent of the threadpool by first creating a channel populated with 5 DB handles, and then each incoming request (which I believe go spawns as its own goroutine) will first "claim" a db handle, do whatever things its needs, then release it back (by writing it back to the channel). Did I get that right? It's very clever, is this an idiomatic Go pattern?

But I'm still a bit confused as to why this is necessary. From the GO Docs on db.open:

>Open opens a database specified by its database driver name and a driver-specific data source name, usually consisting of at least a database name and connection information.

>The returned DB is safe for concurrent use by multiple goroutines and maintains its own pool of idle connections. Thus, the Open function should be called just once. It is rarely necessary to close a DB.

So it seems like you really shouldn't need to worry about manually creating a threadpool (and SQLite itself handles multiple readers). Maybe the speedup you saw is from creating the prepared statement ahead of time?

Post edited on 29th May 2022, 2:10am