we've noticed that too here and quick explanation is - with the new
"prepare" implementation, the query get prepared on the server side,
which is good; the problem is that all of the bind values passed to
the sql server during execute call are in form of ***varchar***, i.e.
even if a field is of int type in postgresql table, DBD::Pg passes
your bind value as char - as a result, postgresql doesn't use indexes.
I don't know if developers of new DBD::Pg have some game plan to fix
this problem... but it won't be easy: since perl is a no-var-type
language, so either DBD::Pg needs to analyze the table columns data
types first before executing a query and then use correct type for
bind values, or let coder pass those types explicitly... though I'm
not aware of a method in DBI that would let them do that...
Anyone from DBD::Pg can comment this please?
I was going to post an example to the list later today.
On Apr 8, 2005 12:30 PM, Brandon Metcalf <bmetcalf(at)nortel(dot)com> wrote:
> Has anyone done any benchmarking between the old Pg interface and
> DBI/DBD::Pg? I have two versions of some code one of which uses Pg
> and the other DBI/DBD::Pg and the latter appears to cause much more of
> load on the system where it's running than the former. However, I
> haven't done any benchmarking to support this claim.
> Dbdpg-general mailing list
pgsql-interfaces by date
|Next:||From: Brandon Metcalf||Date: 2005-04-08 18:17:23|
|Subject: Re: [Dbdpg-general] benchmarking old Pg and DBD::Pg|
|Previous:||From: Tom Lane||Date: 2005-04-08 14:46:02|
|Subject: Re: What is the binary format for timestamps? |