Re: [Ruby-DBI-devel] PGconn::exec vs. PGconn::async_exec benchmark

[Michael N. <mne...@nt...>]

On Wed, May 07, 2003 at 11:03:46AM +0200, Florian G. Pflug wrote:
> On Wed, May 07, 2003 at 10:22:16AM +0200, Michael Neumann wrote:
> > > This is why I put this counter-thread into my benchmark. To show that in the
> > > pseudo-asynchronous case the non-database thread (my counter thread) manages
> > > to do more work, without hurting the performance of the database thread much
> > > (30 ms for 1000 inserts makes 30us/insert)
> > 
> > I think 30us is acceptable (at least, it's for me).
> > 
> > There are now two possible ways to go:
> > 
> > 1) Replace query/exec with asyc_query/async_exec.
> > 
> > 2) Introduce an option "async" => true/false that let you choose
> >    which variant to use.
> 
> I beliebe that other database backends might have the same problem - and for
> some the fix might hurt performance alot. Thats why after thinking about
> this a bit, I believe this should be made an option, but the default should
> be "pseudo-asynchronous" (because in the average case it's the more sensible
> behaviour)

There's currently no other database module that has such pseudo-async
methods (or I am simply not aware of it).

I've come to the conclusion that the best probably is to introduce a
"pg_async_exec" flag and then dependend on this flag execute either
async_exec or exec in the Statement#execute method. Note that all other
methods still call exec. As those calls usually issue COMMIT, ROLLBACK
or BEGIN statements, I don't think there's a big differece when using 
async_exec.  But of course I may be wrong. Or should I use everywhere 
the async method when the flag is set?

Also note, that pg_async_exec will be true by default.

> Maybe some generic name like "assume_fastquery" would be best - since it
> would depend on the backend if it his information is used, and in which way.

As long as there are no other database modules, I am against this.


Regards,

  Michael