I think you are doing something wrong. DBD::Pg is fast-to-unnoticeable.
I bet that with PHP you do your operations within one transaction (do an
explicit BEGIN or whatever way in PHP you start a transaction), whereas in
perl, you don't do $dbh->{AutoCommit}=0;
The best way to kill postgres' performance is to put each statement in its
own transaction (default, AutoCommit=1).
If you post your source code, I might be able to help you out.
-alex
On Mon, 12 Nov 2001, Michael Wray wrote:
> Thanks for the suggestions, but here's my 2 cents on DBI/DBD::Pg:.
>
> I would LOVE to use DBD::Pg...I have written a lot of code using
> DBD::Pg...however...unless there is a Monumental Performance increase
> between DBD::Pg that was out with DBI-1.16, and the current version..I
> don't think I can consider this...That and right now I think I am
> looking at less coding for libpq as most of the routines will port
> straight across from PHP. (Note...I said amateur not NOVICE..)
>
> If I were ONLY doing Report type queries and no UPDATES..then DBI
> would be fine...
>
> I have already tried this project using DBD::Pg...performance from
> DBD::Pg sucked....I am already using the libpq routines in PHP
> (written by another programmer.) with amazing results...from other
> reports I have seen...moving away from apache and going pure perl with
> the Pg module will give me blazing performance. (Yes..PosgtGres)...I
> have no need of porting my code to another database...this is a
> proprietary product and will be maintained and released by this
> company for quite awhile....I need speed..not portability...The way
> they are being used in PHP does not match my needs though and I need
> info on Error response codes from libpq.
>
> DBD adds an extra layer to the programming that I am trying to cut
> out....that extra layer cuts way into performance...
>
>
> I can manually replicate my database faster by hand than by any of the
> available methods in DBD::Pg...and in fact have done so...(And that
> was a LONG night...)
>
>
> My end goal:
>
> Client->Perl->libpq (Pg)->Postgres,
> which sits now as:
> Client->Apache->Php->libpq->PostGres.
> will move to
> Client->Apache->mod_perl->libpq->Postgres...then I will drop Apache...I don't need a
>full fledged WebServer for what I am doing...just a TCP server listening on the same
>port to handle DB queries in the form of a URL request...
> *********** REPLY SEPARATOR ***********
>
> On 11/12/01 at 11:51 AM Rudy Lippan wrote:
>
> >On Mon, 12 Nov 2001, Hardy Merrill wrote:
> >
> >> By "Pg", do you mean PostgreSQL database? The only interface that
> >> I'm aware of for Perl to PostgreSQL is through DBI and DBD::Pg. In
> >> terms of documentation for PostgreSQL, I'd start with the Postgresql
> >> home page at
> >
> >There is(was?) a "Pg" interface to perl:
> >http://search.cpan.org/doc/MERGL/pgsql_perl5-1.9.0/Pg.pm
> >
> >And then there was an attempt to write a pure-perl interface for Postgres.
> >I don't think it ever got very far, and I don't remember the name of the
> >pagkage.
> >
> >DBI/DBD::Pg is the way to go. Performance is very good, and DBI makes it
> >easier for you to port your code to other databases.
> >
> >
> >Rudy
>
> ********************** 2K ******************************
>
>
