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
Since you the action switches from SQL to PL/SQL to enforce the trigger,
it sounds like a context switch to me.
FYI: This can be improved somewhat by adding and rownum 2 into the
WHERE clauses of these. There will be noticable improvement when there
are many child rows.
Jared
[EMAIL
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
I thought as much, from what I've heard and read. Does anyone know if
there's a way to figure out how much overhead the switches generate? I'm
guessing they would show up in trace files in the 'other CPU' category.
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
14 matches
Mail list logo
