I was recently wondering about some issue I had encountered between two tables. If tables undergo a lot of INSERT / UPDATE / DELETE statements, it may appear to be better to remove some constraints, at least temporarily for the loading of data. In this particular case, the foreign key relationship was permanently absent and I found the join between the two tables to be a potential source of bad query execution plans in greater contexts. So my intuition told me that this could be optimised by adding the constraint again, as Oracle would then be able to formally use that information for query transformations. I asked the question on Stack Overflow and it seems I was right:
http://stackoverflow.com/questions/8153674/do-foreign-key-constraints-influence-query-transformations-in-oracle
But what does that mean? It’s simple. If you have two tables A and B, and you join them on A.ID = B.A_ID, having a foreign key constraint on B.A_ID may make all the difference. Let’s say, you execute this:
select B.* from B
join A on A.ID = B.A_ID
Without a foreign key on B.A_ID
When B.A_ID is set (i.e. is not null), there is still no guarantee that there actually exists a corresponding A.ID. A is not part of the projection. Intuitively, it is thus not needed, but it cannot be optimised away, because the query will actually have to check for existing A.ID per B.A_ID.
With a foreign key constraint
When B.A_ID is set, then there must be a corresponding, unique A.ID. Hence, the JOIN can be ignored in this case. This has powerful implications on all sorts of transformation operations.
For more details, have a look at Tom Kyte’s presentation “Meta Data Matters”
