Just remembered this one:
If you update a column which has a bitmap
index, then the entire index is locked,
which means the entire table is locked.
And here's a prediction for Urban Legends 2003/4
Always, always, always use bind variables.
Jonathan Lewis
Jonathan Lewis wrote:
Just remembered this one:
If you update a column which has a bitmap
index, then the entire index is locked,
which means the entire table is locked.
And here's a prediction for Urban Legends 2003/4
Always, always, always use bind variables.
On that line, I've just had a note from Gaja
about my commentary on the line:
Rewrite all correlated subqueries using in-line views.
He was concerned that I may not think the
advice valid. So let me say quite categorically
that the comment was not a criticism of the
technique.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan
Lewis
Sent: Thursday, March 14, 2002 5:26 AM
To: Multiple recipients of list ORACLE-L
Subject: Re: Index Full Scan -- Strange Issue
This leads to another random thought - if there is
a condition in the WHERE clause,
Been a it busy but am following up. Waleed was on target with the question
on the optimizer_index_cost_adj (I owe you a beer, or your favorite
beverage). This particular DB has optimizer_index_cost_adj set to 1. I
originally said I thought it was 30 or 40, not sure why so low but there is
some
Okay... mine...
Just because Oracle allows 1000 columns, you don't have to feel obliged to
make use of that feature for every table.
ALSO, While sometimes if you put every data elelment in a table that you are
likely to query together [(right up to that 1000 column mark) so you can
avoid
Another comment that Gaja made in his note
was that he didn't like using underscore parameters
such as
_unnest_subquery = true.
especially since you can't be sure of the impact
of using a 'functionality' hint globally. And I totally
agree - particularly in this case where we know that
Jonathan Lewis wrote:
So - when you get to that tricky query which
looks as if it could be unnested, but you can't
quite figure out how, maybe all you need to
do is turn:
select
from
where
. (select colx
from
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan
Lewis
Sent: Saturday, March 16, 2002 8:58 AM
To: Multiple recipients of list ORACLE-L
Subject: Re: Fav. Urban Legend...
and if Oracle can unnest the query, Oracle
will unnest the query; for example, in the
case of
Patrice,
You write:
What is the meaning of relational in relational database
again?
Apparently not what you think. The relational in 'relational database'
comes from the term relation--a certain type of mathematical table
in set theory. It has nothing at all to do with relationships (the
In that same vein, ( or is it vane, or maybe even vain? ;) I tried
removing a correlated subquery from a bit of SQL just yesterday.
It was duly replaced with an inline view, and the time to run
the query increased by %20. :)
Jared
On Saturday 16 March 2002 01:53, Jonathan Lewis wrote:
On
It's clear that 9849 is almost twice 4924.29 when the parameter got
doubled. I think if you leave it at the default value (100) the cost will be
100 * 4924.29 = 50 * 9849 = 492450
Regards,
Waleed
-Original Message-
To: Multiple recipients of list ORACLE-L
Sent: 3/16/02 7:48 AM
Been
Waleed,
Right, the pattern in the way the value increases as we bump up
optimizer_index_cost_adj is readily apparent, but, that still doesn't tell
me *how* the final value (4924, 9849, and so on) with 1, 2, or whatever is
calculated. In other words, how did 297 cost for the index full scan
13 matches
Mail list logo
