Question

SELECT cec.*
  FROM mam.category cec


SELECT cec.year, ces.*
  FROM mam.subcategory ces
  JOIN mam.category cec ON CEC.CATEGORY_ID = CES.CATEGORY_ID


SELECT cec.year, ceo.*
  FROM mam.options ceo
  JOIN mam.subcategory ces ON CES.SUBCATEGORY_ID = CEO.SUBCATEGORY_ID
  JOIN olr.iep_cost_est_category cec ON CEC.CATEGORY_ID = CES.CATEGORY_ID

According to a friend, views in oracle are actually faster for cache purposes. Is this true? What about postgresql? I’ve tried google and stackoverflow (closest one is MS SQL).

Answer 1

Views

Views, which means non-materialized views, are not cached. They are simply a prepared SQL statement that is run in place of the view reference in a query. Think of them like macros, or variables holding the SELECT statement contained in the view.

Materialized views (not supported by PostgreSQL) are similar to tables because they can be indexed. But materialized views are notoriously restricted (IE: no non-deterministic values) in what they can support.

Natural JOINs

None of the examples you posted are natural JOINs, which look like this:

      SELECT cec.year, ces.*
        FROM mam.subcategory ces
NATURAL JOIN mam.category cec

The syntax is frowned upon (though being ANSI) because it’s ambiguous at best and leaves you open to problems if:

• columns get added or renamed
• no more than two tables can be joined using this method
• gives you little control over the specifics of a join if columns join across the tables in an unusual way. It’s not obvious what the join criteria is — being explicit is both readable and guarantees consistent results.

Conclusion

Non-materialized views are largely irrelevant with regard for JOIN syntax. Data and indexing will have a larger impact on performance.