Can you tell us what version of the (ahem) unnamed proprietary products
you used? :-). For example if you used version 8i of an unnamed
proprietry product, that might be informative :-).
Ned Lilly wrote:
>
> Marc's right... we opted for ODBC to ensure as much of an "apples to apples"
> comparison as possible. Of the 5 databases we tested, a native driver existed for
> only the two (ahem) unnamed proprietary products - Postgres, Interbase, and MySQL
> had to rely on ODBC. So we used the vendor's own ODBC for each of the other two
> cases.
>
> <disclaimer>
> As with all benchmarks, your mileage will vary according to hardware, OS, and of
> course the specific application. What we attempted to do here was use two
> industry-standard benchmarks and treat all five products the same.
> </disclaimer>
>
> Presumably, if the vendor had taken the time to write a native driver for
> Postgres, the results would have seen an even bigger kick. We don't have any
> reason to think that the results for all five tests in native driver mode would be
> out of proportion to the results we got through ODBC.
>
> Regards,
> Ned
>
> The Hermit Hacker wrote:
>
> > On Mon, 14 Aug 2000, Steve Wolfe wrote:
> >
> > > > 1) Using only ODBC drivers. I don't know how much of an impact a driver
> > > can
> > > > make but it would seem that using native drivers would shutdown one source
> > > > of objections.
> > >
> > > Using ODBC is guaranteed to slow down the benchmark. I've seen native
> > > database drivers beat ODBC by anywhere from a factor of two to an order of
> > > magnitude.
> >
> > I haven't had a chance to take a look at the benchmarks yet, having just
> > seen this, but *if* Great Bridge performed their benchmarks such that all
> > the databases were access via ODBC, then they are using an
> > 'apples-to-apples' approach, as each will have similar slowdowns as a
> > result ...
