Discussion: How to read using a backend thread reader

[davecramer]

This issue is meant to discuss implementation details. At this point no idea is too wacky.

I've been noodling on how to implement a backend thread reader.
One challenge I have is that we don't want to read too much into buffers. Ideally I think we want to keep the data queued up in the network instead of reading it all into buffers and then reading it into the result set. Imagine a large result set with many 1G columns. I imagine this to be an improbable case but regardless I don't think we want to double buffer.

So one thought is to use multiple (at least 2) VisibleBufferedInputBuffers and having a cap on how far we read ahead. This seems to be a viable option as the notion of a read ahead buffer is fairly common.

Thoughts ?
Does anyone know how NIO does it ?

[vlsi]

There are two major approaches:

1. Reactive: consumer asks next elements every time it wants some. This ensures the producer never overflows the consumer. In our case, the consumer could be ResultSet which would ask the background thread to fetch more data which would ask network, and so on.

   A side effect of using a reactive approach is the code becomes extremely hard to reason about.
   See https://www.youtube.com/watch?v=z0a0N9OgaAA

2. Coroutines: https://medium.com/@elizarov/simple-design-of-kotlin-flow-4725e7398c4c
   It results in pretty much the same result, yet the coding model is easier to understand.

[davecramer]

Regarding the consumer idea above. I think it is a bit more complex because we have async events coming out of the database such as NOTIFY. I am struggling with envisioning code that knows in advance what it is expecting, like a ResultSet, vs the notion of async listeners