Ron Johnson wrote:
So why is Perl-SP-INSERT so much slower than Perl-SQL-INSERT?
(I can imagine that the SP code path would be longer, but since IO
is the slowest part of the system, I'm surprised that it's *that*
much slower.)
I'm guessing that since PG allows overloaded SP names, the slowne
Ron Johnson wrote:
Interesting. Does PG have to initiate the Perl interpreter every
time you call a Perl-written SP?
I mean the *application* language was Perl for both the inline insert
and the proc call. The proc was written in plpgsql.
---(end of broadcast)--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ron Johnson wrote:
> On 08/18/07 11:08, Joshua D. Drake wrote:
>> Josh Tolley wrote:
>>> On 8/18/07, Ron Johnson <[EMAIL PROTECTED]> wrote:
Interesting. Does PG have to initiate the Perl interpreter every
time you call a Perl-written SP?
>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/18/07 11:08, Joshua D. Drake wrote:
> Josh Tolley wrote:
>> On 8/18/07, Ron Johnson <[EMAIL PROTECTED]> wrote:
>>> Interesting. Does PG have to initiate the Perl interpreter every
>>> time you call a Perl-written SP?
>> IIRC PostgreSQL should on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Josh Tolley wrote:
> On 8/18/07, Ron Johnson <[EMAIL PROTECTED]> wrote:
>> Interesting. Does PG have to initiate the Perl interpreter every
>> time you call a Perl-written SP?
>
> IIRC PostgreSQL should only load the perl interpreter once per session
On 8/18/07, Ron Johnson <[EMAIL PROTECTED]> wrote:
> Interesting. Does PG have to initiate the Perl interpreter every
> time you call a Perl-written SP?
IIRC PostgreSQL should only load the perl interpreter once per session.
- Josh
---(end of broadcast)--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/17/07 21:45, Steve Manes wrote:
> Ron Johnson wrote:
>>> Moving all the application-bound inserts into stored procedures didn't
>>> achieve nearly the performance enhancement I'd assumed I'd get, which I
>>> figured was due to the overhead of the
Steve Manes wrote:
Moving all the application-bound inserts into stored procedures didn't
achieve nearly the performance enhancement I'd assumed I'd get, which I
figured was due to the overhead of the procs themselves.
That's the conclusion I'm coming to as well for my app with very high
inse
Ron Johnson wrote:
Moving all the application-bound inserts into stored procedures didn't
achieve nearly the performance enhancement I'd assumed I'd get, which I
figured was due to the overhead of the procs themselves.
Would that be because the original app was written in a compiled
language, b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/17/07 18:00, Steve Manes wrote:
> Guy Rouillier wrote:
>> I have a thread I started ages ago over on the PERFORM list that I'm
>> sadly just now being able to provide some insight on. I'll be
>> replying on that thread in more detail, but the sh
Guy Rouillier wrote:
I have a thread I started ages ago over on the PERFORM list that I'm
sadly just now being able to provide some insight on. I'll be replying
on that thread in more detail, but the short of it turns out to be that
at least in this one application, using stored procs for inse
Guy Rouillier wrote:
Steve Manes wrote:
I'm fairly hardcore about keeping as much business logic as I can in
the database. In fact, I only do SELECTs from the application, and
usually via Views. All inserts, updates and deletes are via procs.
...
And, yes, it's faster. Particularly if busin
Steve Manes wrote:
I'm fairly hardcore about keeping as much business logic as I can in the
database. In fact, I only do SELECTs from the application, and usually
via Views. All inserts, updates and deletes are via procs.
...
And, yes, it's faster. Particularly if business logic decisions ha
On 8/16/07, Steve Manes <[EMAIL PROTECTED]> wrote:
> On 8/15/07, Rohit <[EMAIL PROTECTED]> wrote:
>
> Another is because I typically do my web application programming in PHP5
> but the offline scripts in Perl. Both can call the same stored
> procedures so I don't have multiple copies of database c
Rohit wrote:
(4) Is it faster to work at application level or at the database level?
Richard Huxton wrote:
Probably faster in the database, assuming you have only one machine. If
you have more than one machine then you can have each machine designed
for its purpose. Of course, faster to run m
Trevor Talbot wrote:
Another is because I want transactions to start and end in the database,
not in external application code which might crash before a COMMIT.
Hmm, how do you handle this logically? Do your applications never
need to submit chunks of work at once? Or do you do something lik
On 8/15/07, Steve Manes <[EMAIL PROTECTED]> wrote:
> I'm fairly hardcore about keeping as much business logic as I can in the
> database. In fact, I only do SELECTs from the application, and usually
> via Views. All inserts, updates and deletes are via procs. I'm a
> proponent of separating app
On 8/15/07, Rohit <[EMAIL PROTECTED]> wrote:
I have few queries regarding the use of Stored Procedures, Functions
and Triggers in an RDBMS.
(1) When to use Stored Procedure? Writing an INSERT query in a Stored
Procedure is better or firing it from the application level?
(2) Can a Trigger call a
On 8/15/07, Rohit <[EMAIL PROTECTED]> wrote:
> I have few queries regarding the use of Stored Procedures, Functions
> and Triggers in an RDBMS.
>
> (1) When to use Stored Procedure? Writing an INSERT query in a Stored
> Procedure is better or firing it from the application level?
>
> (2) Can a Trig
Rohit wrote:
I have few queries regarding the use of Stored Procedures, Functions
and Triggers in an RDBMS.
These are all easy questions to answer: "it depends".
OK, so you might want some reasons...
(1) When to use Stored Procedure? Writing an INSERT query in a Stored
Procedure is better or
I have few queries regarding the use of Stored Procedures, Functions
and Triggers in an RDBMS.
(1) When to use Stored Procedure? Writing an INSERT query in a Stored
Procedure is better or firing it from the application level?
(2) Can a Trigger call a Stored Procedure?
(3) What type of code must
21 matches
Mail list logo
