Constructor behaviour via INSERT SQL

Question

Interestingly, using an object constructor itself as the insert value seems to have overheads, with the constructor being called multiple times for instantiating the single same object. Cannot recall seeing this documented.
Here's an example (on 11.2.0.2):
// the object type with a custom constructor
SQL> create or replace type TMyRow is object(
  2          id      integer,
  3          day     date,
  4          val     varchar2(10),
  5 
  6          constructor function TMyRow( i integer, d date ) return self as result
  7  );
  8  /
Type created.
// implementation of custom constructor - it uses a dynamic SQL to
// add some "SQL processing noise" for evaluation on how noisy it
// was after a call
SQL> create or replace type body TMyRow as
  2          constructor function TMyRow( i integer, d date ) return self as result is
  3          begin
  4                  DBMS_OUTPUT.put_line( 'constructing TMyRow(): id='||i||' day='||d );
  5                  self.id := i;
  6                  self.day := d;
  7                  self.val := 'TMyRow()';
  8 
  9                  execute immediate 'select '||i||' from dual foo where '||i||'='||i;
10                  return;
11          end;
12  end;
13  /
Type body created.
// table based on object type
SQL> create table mytab of TMyRow(
  2          id primary key,
  3          val default null
  4  ) organization index;
Table created.
// not what I expected - the constructor is actually called 3x and
// not a single time
SQL> insert into mytab values( TMyRow(1, sysdate) );
constructing TMyRow(): id=1 day=2012/04/10 10:21:34
constructing TMyRow(): id=1 day=2012/04/10 10:21:34
constructing TMyRow(): id=1 day=2012/04/10 10:21:34
1 row created.
// from PL/SQL, the constructor is called once only and the
// insert works without "repeating constructor" calls
SQL> declare
  2          myRow TMyRow := new TMyRow(2, sysdate);
  3  begin
  4          insert into mytab values myRow;
  5  end;
  6  /
constructing TMyRow(): id=2 day=2012/04/10 10:21:34
PL/SQL procedure successfully completed.
// as an alternative to the above 2 approaches, one can also
// use a select against DUAL to generate the object to insert -
// however it also shows 3x constructor executions
SQL> insert into mytab select TMyRow(3, sysdate) from dual;
constructing TMyRow(): id=3 day=2012/04/10 10:21:34
constructing TMyRow(): id=3 day=2012/04/10 10:21:34
constructing TMyRow(): id=3 day=2012/04/10 10:21:34
1 row created.
// the rows in the table (no duplicates of course created)
SQL> select * from mytab;
        ID DAY                 VAL
         1 2012/04/10 10:21:34 TMyRow()
         2 2012/04/10 10:21:34 TMyRow()
         3 2012/04/10 10:21:34 TMyRow()
// and here we can see the "noise factor" of the constructor - including
// that it indeed executed 3x for the same object instantiation
SQL> select executions, sql_text from v$sqlarea where upper(sql_text) like 'SELECT%FROM DUAL FOO%' order by 2;
EXECUTIONS SQL_TEXT
         3 select 1 from dual foo where 1=1
         1 select 2 from dual foo where 2=2
         3 select 3 from dual foo where 3=3
         1 select executions, sql_text from v$sqlarea where upper(sql_text) like 'SELECT%FROM DUAL FOO%' order by 2
// if the DUAL select is unbundled from the above SQL insert, the
// constructor is only executed once
SQL> select TMyRow(3, sysdate) from dual;
TMYROW(3,SYSDATE)(ID, DAY, VAL)
TMYROW(3, '2012/04/10 10:21:47', 'TMyRow()')
constructing TMyRow(): id=3 day=2012/04/10 10:21:47Why 3x? The reason seems to be the column count. 3 columns in table (3 properties in object).
4 properties or columns? Constructor is called 4x. 8 properties or columns? Constructor is called 8x.
Ugly, and very much an unexpected, overhead. Is this behaviour documented somewhere? (I could not find anything - but then I was also not sure how express this issue as a meaningful search term)

Answer 1

But it does not occur when calling a PL/SQL function that is not a constructorWith respect yes it does. You did not either explicitly or implicitly reference the result of that function multiple times. Try with a PL/SQL function that returns and object type with multiple attributes...
SQL> CREATE OR REPLACE FUNCTION f_tmyrow (i INTEGER, d DATE)
  2     RETURN tmyrow
  3  AS
  4     rtn tmyrow;
  5  BEGIN
  6     DBMS_OUTPUT.put_line ('returning TMyRow(): id=' || i || ' day=' || d);
  7     RETURN tmyrow (i, d, 'TMyRow()');
  8  END f_tmyrow;
  9  /
SQL> INSERT INTO mytab VALUES (f_tmyrow (1, SYSDATE));
returning TMyRow(): id=1 day=10-APR-12
returning TMyRow(): id=1 day=10-APR-12
returning TMyRow(): id=1 day=10-APR-12
1 row created.
SQL> CREATE OR REPLACE FUNCTION f_tmyrow (i INTEGER, d DATE)
  2     RETURN tmyrow DETERMINISTIC
  3  AS
  4     rtn tmyrow;
  5  BEGIN
  6     DBMS_OUTPUT.put_line ('returning TMyRow(): id=' || i || ' day=' || d);
  7     RETURN tmyrow (i, d, 'TMyRow()');
  8  END f_tmyrow;
  9  /
Function created.
SQL> INSERT INTO mytab VALUES (f_tmyrow (1, SYSDATE));
returning TMyRow(): id=1 day=10-APR-12
1 row created.
SQL>Which also rather interestingly shows that the DETERMINISTIC keyword is observed in SQL (in a within-row context) other than as a requirement for function-based indexes, something which I don't recall noticing before.
When we create a straightforward table of object type (ignoring the matter of substitutable subtypes for the moment) rather than create a single representation of the object Oracle actually creates a relational table with a column for each attribute.
Hence my educated guess would be that an SQL of the form...
INSERT INTO mytab
   SELECT tmyrow (1, SYSDATE)
   FROM   DUAL;...would need to be silently re-written (or at this would be one way of implementing this) to accomodate the above, something like...
INSERT INTO mytab (id, day, val)
   SELECT tmyrow (1, SYSDATE).id,
          tmyrow (1, SYSDATE).day,
          tmyrow (1, SYSDATE).val
   FROM   DUAL d;Note that this is behaviour is similar whether the function being called is a type constructor function, other type method or standalone/packaged PL/SQL function returning object type.
At which point we are tempted to write the above (or question why Oracle does not) to avoid this rather obvious inefficiency.
SELECT d.t.id, d.t.day, d.t.val
   FROM  (SELECT tmyrow (1, SYSDATE) t
          FROM   DUAL) d;Those who have worked with PL/SQL functions in SQL will not be surprised that we do not succeed. Looking at the projection column from explain plan for COUNT (id), COUNT (day), COUNT (val) of this SELECT (the plain SELECT does not yield a value in the projection column), we see we once again have three calls to the function.
COUNT(SYS_OP_ATG("TMYROW"."TMYROW"(1,SYSDATE@!),3,4,2))[22], COUNT(SYS_OP_ATG("TMYROW"."TMYROW"(1,SYSDATE@!),2,3,2))[22], COUNT(SYS_OP_ATG("TMYROW"."TMYROW"(1,SYSDATE@!),1,2,2))[22]If we go a step further and prevent the above view from being merged it forces our projection to be what we want, and we can see from debug that the function is now executed once only.
"ID"[NUMBER,22], "DAY"[DATE,7], "VAL"[VARCHAR2,10]This is all of course identical to how PL/SQL functions behave when queried through in-line views, hence my approach in the previous thread of tuning this as per a normal PL/SQL function call.
What I am unable to explain from the above is that there is an obvious counter-case.
SQL> INSERT INTO mytab (id, day, val)
  2     SELECT d.t.id, d.t.day, d.t.val
  3     FROM   (SELECT tmyrow (1, SYSDATE) t
  4             FROM   DUAL) d;
constructing TMyRow(): id=1 day=10-APR-12
1 row created.
SQL> From what we have seen I would expect this view to be merged and the function to be called three times, as it is with the standalone SQL...
SQL> SELECT d.t.id, d.t.day, d.t.val
  2  FROM   (SELECT tmyrow (1, SYSDATE) t
  3          FROM   DUAL) d;
      T.ID T.DAY     T.VAL
         1 10-APR-12 TMyRow()
SQL> exec null;
constructing TMyRow(): id=1 day=10-APR-12
constructing TMyRow(): id=1 day=10-APR-12
constructing TMyRow(): id=1 day=10-APR-12
PL/SQL procedure successfully completed.
SQL>