On 03/12/14 15:41, Dimitry Sibiryakov wrote: > 12.03.2014 11:33, Alex Peshkoff wrote: >> But if someone wants to built one more level of API_over_ plain >> messages (like it was with SQLDA, but please expandable!) I see no >> problems with it. > SQLDA is expandable. That's what field version is for.
Formally - yes, actually - no. Expanding it is nightmare. Or may be you really think that charset code returned in some fine fields like subtype is because nobody knows about this field? >> Moreover, high >> performance requirements arrive here only when using embedded access and >> processing high volumes of data, returned by engine (something like >> complex statistics analysis). > Do you know that fetch in embedded mode is significantly slower that via > network? No. That is wrong in general case. I know you talk about buffering active only in network case. And I agree that adding it in embedded case is very useful. What I can hardly imagine is efficient buffer with non-plain format of records. It's faster to call high-performance memcpy() once than to perform a lot of small copies from-to random memory places. > Because of it, embedded is not suitable for returning high volumes of data. > I know gbak is outstanding sample, but anyway: # time ./gbak -b /var/stg/gig.fdb qq.zz real 0m44.977s user 0m15.571s sys 0m2.382s # time ./gbak -user sysdba -pas masterkey -b localhost:/var/stg/gig.fdb qq.zz real 2m47.016s user 0m20.643s sys 0m41.019s ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
