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 ...
