On 12/11/14 00:22, Dmitry Yemanov wrote: > Mark et al, > > > 1) It looks like Firebird no longer returns the number of rows requested > > by the client. Jaybird (wire protocol) by default requests 400 rows and > > in the past Firebird always returned the requested number of rows, > > unless there were no more rows (status 100). Firebird no longer seems to > > honor this request and returns a lower number of rows. > > At the client library level, p_sqldata_messages is not used to fetch > particular M records, as M is not surfaced in our public API. Instead, > fbclient tries to optimize batched fetches by asking for as much records > as fits inside P (more or less hardcoded) packets. Given the message > size and the protocol buffer size, it calculates M based on P and > requests M rows in p_sqldata_messages. So far so good. > > The problem is that the aforementioned calculation almost never works > properly with the asymmetric protocol. It does not consider VARCHARs > that could be sent with their real (instead of declared) length. It does > not consider new message formatting in the FB3 protocol (NULL bitmask is > sent separately and NULL items are not sent anymore). The client simply > cannot predict how long messages transmitted by the server are and how > many packets they fit. So in the real world, batches were usually > smaller (in terms of packets, not records) than desired. > > So in FB3, we've switched to server-side batch optimization. Now the > server really transmits P packets (still hardcoded) at once, bit not > more than M requested records. This was expected to better serve the > original fbclient intentions, but obviously it breaks Jaybird and > whoever else that expects exactly M records in the batch. > > At the moment, I can think of a simple solution: > > a) limit server-side batch size calculation to the FB3 protocol (and > later) -- thus avoiding any compatibility issues > > b) within the FB3 protocol (and later), allow the client to explicitly > ask for unknown (server-decided) number of rows > > And I need opinions on (b). I don't really want to extend the op_fetch > packet with more fields. Do you think it would it be OK to reserve some > special values for p_sqldata_messages to indicate this? Zero? ULONG(-1)?
Zero is OK. > Any other suggestions? > > Besides, I'm wondering whether it would be a good idea to make P (in the > case of server-side batch optimization) configurable via firebird.conf. ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
