stazz / cbam Goto Github PK

Currently a new bind message is allocated on every row of batch send. This causes unnecessary GC pressure, since the Bind message is completely owned by send method, and could be easily reused.

Certain SQL statements (at least UPDATE with RETURNING) seem to hang indefinetly when used in conjunction with AnyAsync() from UtilPack.AsyncEnumeration. Need to find repro and fix the underlying problem.

Add SupportsConcurrentEnumeration readonly property to Connection in order for clients to be able to adapt to different situations.

Currently, the CBAM.PostgreSQL.Implementation protocol always tells the backend to send its data in textual format. This is because the bind message is sent before describe, which I think is because we are using portal instead of statement (the batch execution uses statement, and it sends those in different order).

It should be investigated as to how properly allow users to active binary read functionality. One way could be via configuration, in protocol section, where some related information already exists now.

Make it possible to create dedicated connections in CBAM.NATS and CBAM.HTTP (when HTTP supports HTTP v2 protocol) projects. These connections would have their SupportsConcurrentEnumeration property to be set as false, and would be able to optimize their memory usage (e.g. allocating byte arrays for messages) for situations when concurrent enumeration is not needed (which happens often).