Thanks for the suggestion. I believe that those settings worked with the original WordPress theme that I used, but that WordPress theme did not handle wide code sections very well. When I switched to the current “Freshy” theme the settings on that page no longer controlled the format of the dates for the blog articles nor for the comments. Looking through the raw CSS stylesheet, I do not see how the date format was changed by the “Freshy” theme.

This is just a minor issue, so I am not too concerned about the date format.

I guess that I should have looked at the book reviews before quoting from that book (I have not read that book). On a positive note, the book did receive four 5 star reviews, so someone liked the book (maybe the owner of the DeepThinking site). I think that I recognize the names of a couple of the people who wrote some of those reviews.

The display of the dates is one of the few problems that I have with this WordPress theme – that is why I write the date on the first line of each article. I have no control over the formatting of the dates. The dates of the comments are actually at the right side of the comment:
8
03
2010

I guess that is supposed to mean March 8, 2010.

By the by, if you could put date as well as time on the comments, that might be userful.

The original text is basically explaining that NOT EXISTS is preferred to NOT IN. Unfortunately the author forgets to put in the join to correlate the sub-query. He then goes on to explain that an outer join is often quicker than a NOT EXISTS. Although you’ve demonstrated current releases of the optimiser handle them the same.

Interesting that the author didn’t suggest a MINUS which in some circumstances can be even quicker.
e.g.
SELECT BOOK_KEY FROM T5
MINUS
SELECT BOOK_KEY FROM T6

No need to get as far as that, you’ll find that you can’t insert those two rows into that table in that fashion. It’s rather difficult to avoid the conclusion that the output was most likely made up.

Best regards

Maxim

That is a tough problem.

When you are counting on the character of the code to tell you if you have ERRORed, maybe you should be counting on using something else? At least that is what Word’s character counter told me.

Thanks for stopping by. That, unfortunately, is the problem. When something is repeated often enough by enough people, there is a good chance that others will start believing that what is stated is true. If it had not been for Simon’s post in this thread, someone might be tempted to file a bug report on Metalink to report that Oracle is returning the wrong query results.

I do not know who originally created that piece of SQL code. A Google search finds a blog article dated October 10, 2008, another blog article dated July 27, 2009, a news article dated July 5, 2009, and a book with a copywrite date of 2004 – but the SQL statement might have been kicking around long before 2004.

Thanks for stopping by. Your fix is correct, however… now the original documents that recommend the modification to the SQL statement do not make sense, at least with any supported release of Oracle Database. I was hoping that someone would supply the corrected SQL statement, thanks.

A demonstration using my automated tool for generating DBMS_XPLAN output

The SQL statement from the web pages that actually worked as expected:

SQL_ID  9wygcmywqnakk, child number 0
-------------------------------------
SELECT B.BOOK_KEY  FROM T5 B , T6 S WHERE     B.BOOK_KEY=S.BOOK_KEY(+)    AND S.BOOK_KEY IS NULL
 
Plan hash value: 4037983709
 
----------------------------------------------------------------------------------------------------------------
| Id  | Operation          | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
----------------------------------------------------------------------------------------------------------------
|*  1 |  HASH JOIN ANTI    |      |      1 |      1 |     10 |00:00:00.01 |       6 |  1517K|  1517K| 1043K (0)|
|   2 |   TABLE ACCESS FULL| T5   |      1 |     20 |     20 |00:00:00.01 |       3 |       |       |          |
|   3 |   TABLE ACCESS FULL| T6   |      1 |     20 |     20 |00:00:00.01 |       3 |       |       |          |
----------------------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - access("B"."BOOK_KEY"="S"."BOOK_KEY")
 
Note
-----
   - dynamic sampling used for this statement

Your correctly fixed version of the SQL statement:

SQL_ID  0chf1vyy804cz, child number 0
-------------------------------------
SELECT BOOK_KEY  FROM T5 WHERE     NOT EXISTS (SELECT BOOK_KEY FROM T6 WHERE T5.BOOK_KEY = T6.BOOK_KEY)
 
Plan hash value: 4037983709
 
----------------------------------------------------------------------------------------------------------------
| Id  | Operation          | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
----------------------------------------------------------------------------------------------------------------
|*  1 |  HASH JOIN ANTI    |      |      1 |      1 |     10 |00:00:00.01 |       6 |  1517K|  1517K| 1111K (0)|
|   2 |   TABLE ACCESS FULL| T5   |      1 |     20 |     20 |00:00:00.01 |       3 |       |       |          |
|   3 |   TABLE ACCESS FULL| T6   |      1 |     20 |     20 |00:00:00.01 |       3 |       |       |          |
----------------------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - access("T5"."BOOK_KEY"="T6"."BOOK_KEY")
 
Note
-----
   - dynamic sampling used for this statement

Still not obvious why the plans look very, very similar on Oracle 10.2.0.x? Let’s look at a portion of the 10053 trace file:

The SQL statement from the web pages that actually worked as expected:

******************************************
Current SQL statement for this session:
SELECT B.BOOK_KEY  FROM T5 B , T6 S WHERE  
  B.BOOK_KEY=S.BOOK_KEY(+) 
  AND S.BOOK_KEY IS NULL 
*******************************************
...
*********************************
(newjo-save)    [1 0 ]
Final - All Rows Plan:  Best join order: 1
  Cost: 4.5107  Degree: 1  Card: 1.0000  Bytes: 26
  Resc: 4.5107  Resc_io: 4.0000  Resc_cpu: 3241267
  Resp: 4.5107  Resp_io: 4.0000  Resc_cpu: 3241267
kkoipt: Query block SEL$6E71C6F6 (#0)
******* UNPARSED QUERY IS *******
SELECT "B"."BOOK_KEY" "BOOK_KEY" FROM "TESTUSER"."T5" "B","TESTUSER"."T6" "S" WHERE "B"."BOOK_KEY"="S"."BOOK_KEY"
kkoqbc-end
          : call(in-use=41424, alloc=49080), compile(in-use=43232, alloc=47000)
apadrv-end: call(in-use=41424, alloc=49080), compile(in-use=44176, alloc=47000)

Your correctly fixed version of the SQL statement:

******************************************
Current SQL statement for this session:
SELECT BOOK_KEY  FROM T5 WHERE  
  NOT EXISTS (SELECT BOOK_KEY FROM T6 WHERE T5.BOOK_KEY = T6.BOOK_KEY) 
*******************************************
...
*********************************
(newjo-save)    [0 1 ]
Final - All Rows Plan:  Best join order: 1
  Cost: 4.5107  Degree: 1  Card: 1.0000  Bytes: 26
  Resc: 4.5107  Resc_io: 4.0000  Resc_cpu: 3241267
  Resp: 4.5107  Resp_io: 4.0000  Resc_cpu: 3241267
kkoipt: Query block SEL$5DA710D3 (#1)
******* UNPARSED QUERY IS *******
SELECT "T5"."BOOK_KEY" "BOOK_KEY" FROM "TESTUSER"."T6" "T6","TESTUSER"."T5" "T5" WHERE "T5"."BOOK_KEY"="T6"."BOOK_KEY"
kkoqbc-end
          : call(in-use=42280, alloc=49080), compile(in-use=66776, alloc=105192)
apadrv-end: call(in-use=42280, alloc=49080), compile(in-use=67720, alloc=105192)

Those SQL statements directly below the “******* UNPARSED QUERY IS *******” lines from the 10053 trace files sure do look to be similar.

This SQL statement transformation might be a news-worthy development, especially for those who are still working from Oracle 8i SQL references.