Entity/table for connection pooling?

[KnowZero]

I see for the normal async there is a way to get the entity you wish to connect to. But for the async pool, there isn't.

I could run a switch on every connection, but since it seems to send something to server, I am guessing there is a penalty? It would be nice if we can have the connections in the pool be able to be set with whichever entity/table we wish to use.

Or maybe better assign a certain amount of connections per entity/table? This way it would avoid the penalty for lookup when switching? (unless the penalty isn't per connection/session?)

---

Also, a little side comment. Not sure if you prefer it as a separate issue or here is fine. But the docker "latest" and "next" are the same thing (v0.8) where as latest should be v0.7.5. It also may make more sense to have smaller builds debian-slim / almalinux-minimum / almalinux-micro / alpine linux(if there is no issue with musl) instead of just the full stable build.

[ohsayan]

Thanks for bringing this up.

1. The connection pool (sync/async) is simply a collection of connections to the Skytable server. Since the entity is local to every connection, the only way to do it currently is by getting a connection from the pool and switching the entity, like you have noted

2. And you are correct: there is a lookup penalty. This was actually discussed sometime back on our chat channel. The best way to do this is by redefining what the Connection structure looks like to include an entity field (possibly a boxed slice):

      pub struct Connection {
          entity: (Ks, Tbl),
          ...
      } 

   So, whenever you attempt to switch, it'll check whether you're already using that entity. This is far better than sending a request to the server only to find out that you're already using the same entity

3. Assigning a number of connections to a given entity actually seems like a very good idea. I think we can discuss this further. Although, you can always create multiple pools for every entity that you plan to access, but I agree, having library-level support would be very convenient

4. Regarding the Docker image, can you please open an issue here? If you check this post on planned changes to Docker images it can explain some things, and what we plan to do ahead

[MuhtasimTanmoy]

What would be the high-level design for this issue?

[ohsayan]

As we have an opportunity to break (haha) the existing protocol in the next release, I think it will actually be a great idea to build this right into the protocol layer (since the cluster client itself requires some synchronization similar to this). Client @ 0.9 will have this built-in and far more efficient than what i suggested earlier last year.

ETA 2 weeks