On 07-04-2011 18:34, Vlad Khorsun wrote: >> There is a simple change which makes it much faster, tested with Linux >> 2.5 embedded restore: > > Well done ;) > > ... >> My change creates this BLR: >> blr_loop >> blr_receive >> blr_store >> ... >> >> Calls isc_start_and_send first time then N-1 isc_send. > > Very good example of very old feature almost not used for a long time. > Do you have idea how it could be propagated at DSQL level ? I.e. we could > introduce > some special syntax to create input stream of messages (like SUSPEND but > waiting > for next input message). > Yes. We also need it to create aggregate PSQL functions. Each "SUSPEND" would make the function receive updated data on its parameters.
>> I suppose this works in all GBAK versions. > > I see no reason for it to not work ;) > >> PS: There is other restore improvement capable of take down time from >> around 8.5s to 0.5s over TCP, but it still requires some analisys. > > Very interesting. Let me guess... batching of records ? > Yes. Having N sends, we could multiple columns by B (batch factor) and divide N by B. This makes remote (tested with localhost) very fast. This could be done manually in gbak without API changes. But when taking remote out, it's where the problem shows. It could be faster, but could be slower. I'm profiled it and looks like large message increases too much the number of cache misses and make things slower. For example, inserting in my table with one field could use a batching factor of 255 (maximum number of contexts) and is faster than with B = 1. For T10 with B = 5 it's faster, but for some (difficult to measure) larger B, it become slower. I do have some raw ideas to make batching on the message and request API, changing fetch to not return 100/101 but count of messages, and make possible to use input messages where is truly many messages concatenated. SQLDA API could also be adapted, as it works on top of the message API. Adriano ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
