perf(pg-pool): optimize client retrieval from pool by prioritizing prepared client

[cesco69]

see #3397

Instead of retrieving the first available client from the pool, check if there is a free client that already has cached prepared statements. This could improve performance by reducing the need to re-prepare statements on different clients.

[charmander]

Needs tests.

[brianc]

I'm not convinced this is a fair test. In fact, I should check that the query was executed with the same client, but how can I tell if it's the same client?

You can call pg_backend_pid() in a query - that should return the connection ID which will certainly be the same across queries on the same client.

[cesco69]

I'm not convinced this is a fair test. In fact, I should check that the query was executed with the same client, but how can I tell if it's the same client?

You can call pg_backend_pid() in a query - that should return the connection ID which will certainly be the same across queries on the same client.

Thanks! done with 20e7fa2

[brianc]

While I appreciate the thought here....I'm thinking this might be a bit over-optimization and prioritizing a somewhat lesser used use-case over the general purpose. For example, applications that don't use named queries will incur an additional for-loop over the connection pool every time issuing a query via pool.query. It also complicates the pool's api surface slightly by including the name of the query more prominently....which could potentially impact future enhancments like "auto-prepare named statements" where we use md5s of query texts to manage the preparation or something fancier. Finally, and IMO most importantly: in any application under sufficient load, in which this feature would expect to potentially cause performance improvements, your pool will likely be saturated and since every client will be "hot," eventually every client will end up w/ the named queries stored & cached anyway....making this code not really needed. I think the largest measurable performance impact above and beyond what using named prepared statements already makes in applications underload is likely in micro-benchmarks....which isn't worth complicating the API surface for.

[cesco69]

Hi, thanks for the review!

For example, applications that don't use named queries will incur an additional for-loop over the connection pool every time issuing a query via pool.query

No, query without "name" don't are affected by my PR

It also complicates the pool's api surface slightly by including the name of the query more prominently

Absolutly true! I don't found a way for retrive the query "name" from the pool class. If there are a way for retrive the query "name" into _pulseQueue method of Pool class, I can rewrite my PR in more simple way!