I have always been puzzled by the expression
context switch when talking about sql and pl/sql.
To me, a context switch is something that happens
at the O/S level when a process is suspended by the
scheduler and a different process is resumed. If a
trigger fires on an insert/update/delete, this
Most of your cost there comes from the fact that
the triggered approach turns an array process into
a single row process. If you want a fairer comparison
you need to ensure that your raw bulk load is only
processing one row at a time.
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
Don't worry about the fact that it is inefficient,
worry about the fact that it simply doesn't work
Person 2 inserts a row into table ''ApplicationFormCriteria''
but doesn't commit. The 'pseudo-RI' trigger fires and finds
the parent row in 'ApplicationForm' so the row is deemed
okay.
Person 1
Title: RE: Do triggers cause a context switch between SQL PL/SQL
Jonathan
it is switching from SQL context to PL/SQL context and vice versa.
Raj
Rajendra dot Jamadagni at nospamespn dot com
All Views
triggers cause a context switch between SQL PL/SQL
I have always been puzzled by the expression
context switch when talking about sql and pl/sql.
To me, a context switch is something that happens
at the O/S level when a process is suspended by the
scheduler and a different process is resumed
But that's begging the question.
What actually occurs that allows you to
say that there is a context switch ?
I know that one of the advertised performance
enhancements in v9 was the 'more efficient
context switching between SQL and PL/SQL'
(or some such thing) - but a name is not a thing.
Does
Title: RE: Do triggers cause a context switch between SQL & PL/SQL
I am
not sure ... so far as I know "select count(*) from some_table" without any
further group by has always resulted in on
Title: RE: Do triggers cause a context switch between SQL PL/SQL
Well yes. I was pointing out a second way to write the query that avoided selecting from dual. But the time it takes to run the query is the same in both examples.
-Original Message-
From: Jamadagni, Rajendra [mailto
Question:
If some idiot decides to circumvent Oracle's referential integrity and
re-implement it by using triggers (insert, update, delete) that checks the
foreign (parent/child) key fields in other tables like this,
declare numrows INTEGER;
begin
-- ApplicationForm is used if the state and
PROTECTED]
Sent by: [EMAIL PROTECTED]
04/01/2003 09:48 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:Do triggers cause a context switch between SQL PL/SQL
Question:
If some idiot decides to circumvent
Title: RE: Do triggers cause a context switch between SQL PL/SQL
Yes ...
Raj
Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are strictly personal.
QOTD: Any clod can have facts
to ORACLE-L
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:Do triggers cause a context switch between SQL
PL/SQL
Question:
If some idiot decides to circumvent Oracle's referential integrity and
re-implement it by using triggers (insert
Title: RE: Do triggers cause a context switch between SQL PL/SQL
A context switch is order because a trigger is a pl/sql object ...
if you can change the trigger ... instead of count(*) try using exists assuming you have a usable index ...
select count(*)
into numrows
from dual
where
:
[EMAIL PROTECTED] Subject: Re: Do triggers cause a
context switch between SQL PL/SQL
Title: RE: Do triggers cause a context switch between SQL PL/SQL
Your query with the exists would be the same as doing this, right?
select count(*)
into numrows
from from ApplicationFormCriteria
where ApplicationFormCriteria.applicationFormId = :old.applicationFormId
and rownum = 1
15 matches
Mail list logo
