Re: Performance: Perl-DBI vs. PG Stored Procedures

From: David Link <dlink(at)soundscan(dot)com>
To: Alex Avriette <a_avriette(at)acs(dot)org>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Performance: Perl-DBI vs. PG Stored Procedures
Date: 2001-11-21 14:21:27
Message-ID: 3BFBB867.85A9E635@soundscan.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

How does the fact that the program is stored in the postgres make it
faster? Or perhaps the question: How much performance overhead is
there to use the Perl:DBi and Perl:DBD packages? -- Do they rely on
ODBC?

Also, what do you mean by doing nested selects in perl with arrays and
hashes? Do you mean break the SQL query up into parts and run them
separately and combine them in Perl itself?

Thanks for your reply.
David

Alex Avriette wrote:
>
> Yes. The PL/SQL programs will be faster since theyre stored in postgres.
>
> Doing things like nested selects, however, will be faster in perl with
> arrays/hashes than they would be in sql. you might also consider dropping
> any indexes you have before inserting and then re-creating them. this is
> provided, of course, you only have one concurrent user.
>
> alex
>
> -----Original Message-----
> From: David Link [mailto:dlink(at)soundscan(dot)com]
> Sent: Tuesday, November 20, 2001 11:10 AM
> To: pgsql-general(at)postgresql(dot)org
> Subject: [GENERAL] Performance: Perl-DBI vs. PG Stored Procedures
>
> Hi,
>
> Could there be performance gains by using PG stored procedures rather
> than using generic Perl DBI programs?
>
> Namely for a task that loops thru a cursor of several 50,000 rows and
> does UPDATES or INSERTS back into that same table. It is takes hours.
>
> Thanks, David
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2001-11-21 14:55:38 Re: indexing bug?
Previous Message Martijn van Oosterhout 2001-11-21 14:04:58 Re: Determining which index to create