Given that Firebird's wire protocol is a known bottleneck, anything that
reduces that data transmitted (time spent) on the wire will improve
performance. We can blame Borland for a crummy wire protocol, but we
don't have to be tied to Borland's past mistakes.

Batching is becoming a quasi-standard feature since it is explicitly
supported as an option (not a requirement) in the JDBC interface
specification.

Of course, it may not be reasonable to do this without serious rewrite.
I would suggest leaving documented hooks for future extensions in the
Vulcan rewrite, then there is a place for the _optional_ extension,
should someone in the future want to take up the feature after the wire
protocol has been revamped.


On Sun, 2005-06-12 at 16:56 +0000, Firebird-Architect@yahoogroups.com
wrote:

> Message: 1
> Date: Sat, 11 Jun 2005 22:39:12 -0400
> From: "Ann W. Harrison" <aharrison@...>
> Subject: Re: Batch statements
>
> Rick Debay wrote:
> > This cuts down on network overhead significantly, batches of statements
> > that took hours in SQL Server went to just under one hour.
>
> It's relatively late on a Saturday night and I've spent the whole day
> doing varnish yoga in 30 degree heat and 90% humidity, so my humor and
> perspective may be completely gone, but ....
>
> Not everything that improves the performance of SQL Server, Sybase,
> Oracle, DB2, MySQL, Postgres, Ingres, SQLLite, SleepyCat, or MyISAM
> improves the performance of others. Generalizing from the changes on
> one system to requiring all to provide the same extra-standard features
> makes those of us who are hot, sunburned, lame, and cranky write rude
> responses.
>
> Cheers,
>
>
> Ann
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
>
>
> ------------------------------------------------------------------------
> Yahoo! Groups Links
>
>
>
>
> ------------------------------------------------------------------------
>
>
>
>