Re: DB access speeds, App(linux)<->PG(linux) vs App(linux) <->MSSql(Windows)

OK, so there is a DBD for sybase that you are leveraging to interface with the MSSql DB.  And that would be roughly
equivilentto the DBD for PG in terms of performance.  I mentioned odbc because I thought that was the common thread to
useto bridge perl to the MSSql DB.  ANd I saw that has introducing more translation steps (slower).
 

Yes, everything else is a constant between the two (network distance, server size/mem, etc...)

I think this answers my question.  Thanks everyone. 

-----Original Message-----
From: Francisco Olarte [mailto:folarte@peoplecall.com] 
Sent: Wednesday, June 24, 2015 12:50 PM
To: Gauthier, Dave
Cc: Postgres General
Subject: Re: [GENERAL] DB access speeds, App(linux)<->PG(linux) vs App(linux) <->MSSql(Windows)

Hi Dave:

On Wed, Jun 24, 2015 at 3:44 PM, Gauthier, Dave <dave.gauthier@intel.com> wrote:
> Hi:  I'm trying to get a 10,000 ft understanding of the difference in 
> DB access speeds for two different scenarios...
> Scenario 1:     Apps are on linux.  PG DB is on linux (different server than
> apps)
>
> Scenario 2:     Apps are on linux.  MSSql DB is on Windows (obviously a
> different server)
>
> The apps are typically perl scripts using Perl DBI.
> I'm thinking that since perl has a DBD driver for PG, that would be 
> faster than going through ODBC to get to the MsSQL DB, but I'm not sure about that.
> Any insights/guesses ?

From 10k ft, same speed ( variations due to lack of precision in the definition of the problem are going to dwarf
everythingelse ).
 

I assume apps are the same on both, and same network distance. If you use DBI for both you can discount it. If you use
DBIyou must use DBD.
 
DBD::Pg is quite efficient in my measurements, but for the windows part I do not know what you are using. I'm using
Mssqlfrom linux using freetds ( DBD::Sybase, built with freetds, which is equivalent to DBD::Pg built with libpq ) and
itgoes at the appropiate speed ( I mean, nothing big is going to be gained, optimization time will be bigger than
savings). You say you use ODBC, but where exactly? You use ODBC on linux going to mssql using ¿which library? and
DBD::ODBC,or you use remote odbc and an ODBC driver on windows?
 

In any way, speed differences in your queries may be much bigger than requester speeds, unless you have a very complex
path( dbd::proxy going to a windows perl dbiproxy going with DBD::odbc to local mssql ?
 
). You should time a couple of your queries in real world condition, and test some loops of null queries ( like select
1and the mssql equivalent in autocommit and no autocommit mode for both ), either of them can win.
 

Also, someone has already told you that for really fast queries native may make a difference. It may, but you have to
define'non native'
 
better. In very fast queries requester differences may be dwarfed by network roundtrips, and if this is a problem to
you,you should look for optimizing the common path firsts, things like how many roundtrips each PROTOCOL needs for the
smallquery and other similar. You should measure before. Requester is not normally going to be your big problem.
 

Francisco Olarte.