Re: Embedded SQL inherently faster than others? - Mailing list pgsql-general

From
Subject Re: Embedded SQL inherently faster than others?
Date
Msg-id 0A5B2E3C3A64CA4AB14F76DBCA76DDA48BFAB8@seifur.hnit.is
Whole thread Raw
In response to Embedded SQL inherently faster than others?  (leinfidel@netscape.net (Kevin))
Responses Re: Embedded SQL inherently faster than others?
Re: Embedded SQL inherently faster than others?
List pgsql-general


> -----Original Message-----
> From: pgsql-general-owner@postgresql.org
> [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Kevin
> Sent: 4. maí 2004 17:18
> To: pgsql-general@postgresql.org
> Subject: [GENERAL] Embedded SQL inherently faster than others?
>
>
> Hello,
>
> I've read when using embedded sql with an Oracle database,
> it's faster than other methods of database interaction, due
> to the way it interacts with the Oracle DB.
>


Is it? If we are talking about embeded SQL into the C/C++ then I think it is
tranlslated into OCI(Oracle Call Interface) calls which are the same API used
by not embeded SQL.
May be the efficiancy comes in more efficient OCI use when automatically
generated than manually written OCI calls, for example, less parse calls?


If this is SQLJ(Java) embeded SQL  then it is cleary translated into normal
JDBC calls - again, the no "other way" to interact the database.


If this is PL/SQL stored procedures then yes, appearently the interaction
bypasses the whole network layer and probably much more.

DB2, as far as I know, uses some precompiled SQL files which may make a
difference if used or not used.
Oracle is using so called "shared pool" memory region for this reason - it's
where Oracle stores compiled SQL. Client API submits SQL strings just
literally, db engine searches them in the shared pool (the  performance of
this search is a big issue for Oracle)  - if not found then it makes a big
deal(time) to compile. This said we see that what ever Oracle API is used:
SQL strings goes to db engine from the client API.

Regards, Laimis




pgsql-general by date:

Previous
From: Dardo D Kleiner - CONTRACTOR
Date:
Subject: Re: Load Balancing and Backup
Next
From: Tom Lane
Date:
Subject: Re: vacuumdb is failing with NUMBER OF INDEX TUPLES NOT THE SAME AS HEAP