efficient than a SM join when there is adequite
hash area available
Kevin
T
-Original Message-From: Sai Selvaganesan
[mailto:[EMAIL PROTECTED] Sent: Wednesday, October 08, 2003
3:50 PMTo: Multiple recipients of list ORACLE-LSubject:
RE: FIRST_ROWS hints
tried that to
tried that too.infact i changed the db_file_multiblock_read_count to a very small value about 1/8 of the previous value. for it to move from SM to NL in only one case.
generally,it is using SJ only.and right i have started seeing a lot of full table scans.
apparently the general recommendation
Did you remember to cut the db_file_multiblock_read_count
in half, since you doubled the blocksize? I would assume that you also started
seeing more full table scans, as well.
Scott Canaan ([EMAIL PROTECTED])
(585) 475-7886
"Life is like a sewer, what you get
out of it depends o
Very Much expected behaviour. Your increase in the db_block_size from 8 to
16, is making the optimizer choose full table scans, where applicable,
since you have to scan through only half the number of blocks now.
A nested loop will starting throwing the initial results faster. A sort
merge join m
