Using Pipeline Table functions with other tables

Question

I am on DB 11.2.0.2 and have sparingly used pipelined table functions but am considering it for a project that has some fairly big (lots of rows) sized tables. In my tests, selecting from just the pipelined table perform pretty well (whether it is directly from the pipleined table or the view I created on top of it). Where I start to see some degregation when I try to join the pipelined tabe view to other tables and add where conditions.
ie:
SELECT A.empno, A.empname, A.job, B.sal
FROM EMP_VIEW A, EMP B
WHERE A.empno = B.empno AND
      B.mgr = '7839'
I have seen some articles and blogs that mention this as a cardinality issue, and offer some undocumented methods to try and combat.
Can someone please give me some advice or tips on this. Thanks!
I have created a simple example using the emp table below to help illustrate what I am doing.
DROP TYPE EMP_TYPE;
DROP TYPE EMP_SEQ;
CREATE OR REPLACE TYPE EMP_SEQ AS OBJECT
       ( EMPNO                                         NUMBER(10),
         ENAME                                         VARCHAR2(100),
         JOB                                           VARCHAR2(100));
CREATE OR REPLACE TYPE EMP_TYPE AS TABLE OF EMP_SEQ;
CREATE OR REPLACE FUNCTION get_emp return EMP_TYPE PIPELINED AS
BEGIN
  FOR cur IN (SELECT
                empno,
                ename,
                job
              FROM emp
         LOOP
           PIPE ROW(EMP_SEQ(cur.empno,
                            cur.ename,
                            cur.job));
         END LOOP;
         RETURN;
END get_emp;
create OR REPLACE view EMP_VIEW as select * from table(get_emp());
SELECT A.empno, A.empname, A.job, B.sal
FROM EMP_VIEW A, EMP B
WHERE A.empno = B.empno AND
      B.mgr = '7839'

Answer 1

I am on DB 11.2.0.2 and have sparingly used pipelined table functions but am considering it for a project that has some fairly big (lots of rows) sized tables
Which begs the question: WHY? What PROBLEM are you trying to solve and what makes you think using pipelined table functions is the best way to solve that problem?
The lack of information about cardinality is the likely root of the degradation you noticed as already mentioned.
But that should be a red flag about pipelined functions in general. PIPELINED functions hide virtually ALL KNOWLEDGE about the result set that is produced; cardinality is just the tip of the iceberg. Those functions pretty much say 'here is a result set' without ANY information about the number of rows (cardinality), distinct values for any columns, nullability of any columns, constraints that might apply to any columns (foreign key, primary key) and so on.
If you are going to hide all of that information from Oracle that would normally be used to help optimize queries and select the appropriate execution plan you need to have a VERY good reason.
The use of PIPELINED functions should be reserved for those use cases where ordinary SQL and PL/SQL cannot get the job done. That is they are a 'special case' solution.
The classic use case for those functions is for the transform stage of ETL where multiple pipelined functions are chained together: one function feeds its rows to the next function which feeds its rows to another and so on. Each of those 'chained' functions is roughly analogous to a full table scan of the data that often does not need to be joined to other data except perhaps low volumn lookup tables where the data may even be cached.
I suggest that any exploratory or prototyping work you do use standard relational tables until such point as you run into a problem whose solution might require PIPELINED functions to solve.