From: | <lnd(at)hnit(dot)is> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Embedded SQL inherently faster than others? |
Date: | 2004-05-05 16:35:33 |
Message-ID: | 0A5B2E3C3A64CA4AB14F76DBCA76DDA48BFAB8@seifur.hnit.is |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> -----Original Message-----
> From: pgsql-general-owner(at)postgresql(dot)org
> [mailto:pgsql-general-owner(at)postgresql(dot)org] On Behalf Of Kevin
> Sent: 4. maí 2004 17:18
> To: pgsql-general(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dardo D Kleiner - CONTRACTOR | 2004-05-05 16:40:26 | Re: Load Balancing and Backup |
Previous Message | Jan Wieck | 2004-05-05 16:32:39 | Re: [GENERAL] cache lookup of relation 165058647 failed |