Open
Description
The CommandBehavior.SequentialAccess
flag is a hint to the ADO.NET library that rows should not be buffered in memory before being returned. This could reduce memory usage and improve performance for large BLOBs.
This might end up being a significant refactoring of the ResultSet
and Row
classes:
ScanRowAsync
would no longer wait for the entire payload to be received, but just the header byte (to know if EOF or new row)GetValue
would be required to be called in ordinal order, would discard data for columns before the current one, and would potentially block while waiting for more network data to arrive for the desired columnGetFieldValueAsync<T>
should be overridden and do the same, but with proper async supportGetStream
would return a customStream
implementation that returns bytes off the network as they become available (and doesn't support rewinding)GetBytes
andGetChars
would allow forward-only access to chunks of data in the column.
Perhaps it would be easiest to implement this by adding a new derived class (of ResultSet
, and two new Row
classes) and overriding methods to implement the streaming as necessary?
Activity
bgrainger commentedon Jan 6, 2023
FWIW, it sounds like Npgsql used to have something similar (two separate DataReader classes for sequential and non-sequential), but merged them back into one class: npgsql/npgsql#2328.