Given that in the original quote only select on audit trail was mentioned, this might in fact _not_ always be the case.

create index ProcNumConcatIdx
on audit_trail(proc||’-'||num);

select /*+ index(aud ProcNumConcatIdx) */
pck.*
from
package pck,
audit_trail aud
where
pck.caseref=aud.proc||’-'||aud.num;

PLAN_TABLE_OUTPUT
————————————————————————————–
Plan hash value: 4083992475

—————————————————————————————
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
—————————————————————————————
| 0 | SELECT STATEMENT | | 1000 | 13000 | 31 (4)| 00:00:01 |
|* 1 | HASH JOIN | | 1000 | 13000 | 31 (4)| 00:00:01 |
| 2 | TABLE ACCESS FULL| PACKAGE | 1000 | 6000 | 2 (0)| 00:00:01 |
| 3 | INDEX FULL SCAN | PROCNUMCONCATIDX | 9999 | 69993 | 28 (0)| 00:00:01 |
—————————————————————————————

1 – access(“PCK”.”CASEREF”=TO_CHAR(“PROC”)||’-'||TO_CHAR(“NUM”))

select /*+ use_nl(pck aud) index(aud ProcNumConcatIdx) */
pck.*
from
package pck,
audit_trail aud
where
pck.caseref=aud.proc||’-'||aud.num;

PLAN_TABLE_OUTPUT
————————————————————————————–
Plan hash value: 1711062606

—————————————————————————————
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
—————————————————————————————
| 0 | SELECT STATEMENT | | 1000 | 13000 | 1003 (1)| 00:00:13 |
| 1 | NESTED LOOPS | | 1000 | 13000 | 1003 (1)| 00:00:13 |
| 2 | TABLE ACCESS FULL| PACKAGE | 1000 | 6000 | 2 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | PROCNUMCONCATIDX | 1 | 7 | 1 (0)| 00:00:01 |
—————————————————————————————

“I need to join them in the fastest way possible as I am dealing with rather large tables.”

is really the scary bit in the initial question.

Why is it needed to join in the fastest way possible because the tables are big? That makes no sense at all, by itself.

If the number of rows being retrieved in a typical query is small, then the size of the tables we start from is immaterial – assuming of course a sensible indexing strategy.

If the number of rows being retrieved in a typical query is large, then – and only then – does the large size of the tables become critical. Mostly because indexed retrieval may not be the best strategy to read large numbers of rows.

But like you said: there is not enough information in the question to answer it in a consistent fashion.

The problem of course becomes: what happens when I *may* need to retrieve *both* large and small amounts of data from the join? Where is the cutoff point for indexing versus hash/sort-merge and how do I tell the optimizer to go each way depending on my intentions? This is where histograms may help, but often that’s not enough…

I try to promote phraseology such as “I need to join TableA _and_ TableB …” or “… Table A _with_ TableB …”, rather than using “to” so that we avoid prejudging the identification of the driving table.

And there’s also the question, I think, of how often you perform this join. If you generally access TableB only when accessing TableA and joining them together (I’m thinking of an invoice_detail and an invoice_header table accessed through an OLTP system screen or web interface for customer enquiries, for example) then I’d be thinking of clustering as another option.