Разходи за заявка:Глобални временни таблици срещу колекции (виртуални масиви)

Глобалните временни таблици могат да имат статистика като всяка друга таблица. Всъщност те са като всяка друга таблица, имат сегменти от данни, само във временно таблично пространство.

В 11g статистиката е глобална, така че понякога причинява проблеми с плановете за изпълнение. В 12c те са базирани на сесия, така че всяка сесия получава подходящи (ако има такива).

Кардиналността на типа колекция се основава на размера на DB блока и за блока от 8 kB по подразбиране е 8168. Съдържанието на колекцията се съхранява в PGA. Доста обичайно е да се подсказва кардиналността, когато се използват типове колекция в сложни заявки, за да се подскаже оптимизаторът. Можете също да използвате разширен интерфейс на оптимизатор за прилагане на собствен начин за изчисляване на разходите.

Редактиране - добавени тестове:

CREATE TYPE STRINGTABLE IS TABLE OF VARCHAR2(255);
CREATE GLOBAL TEMPORARY TABLE TMP (VALUE VARCHAR2(255));

INSERT INTO TMP SELECT 'Value' || LEVEL FROM DUAL CONNECT BY LEVEL <= 1000000;

DECLARE
    x STRINGTABLE;
    cnt NUMBER;
BEGIN
    SELECT VALUE BULK COLLECT INTO x FROM TMP;

    DBMS_OUTPUT.PUT_LINE(TO_CHAR(SYSTIMESTAMP, 'MI:SS.FF3'));

    SELECT SUM(LENGTH(VALUE)) INTO cnt FROM TMP;

    DBMS_OUTPUT.PUT_LINE(TO_CHAR(SYSTIMESTAMP, 'MI:SS.FF3'));

    SELECT SUM(LENGTH(COLUMN_VALUE)) INTO cnt FROM TABLE(x);

    DBMS_OUTPUT.PUT_LINE(TO_CHAR(SYSTIMESTAMP, 'MI:SS.FF3'));
END;

В този случай достъпът до GTT е около два пъти по-бърз от този до събирането, около 200 ms срещу 400 ms на моята тестова машина. Когато увеличих броя на редовете до 10 000 000, получих ORA-22813:стойността на операнда надвишава системните ограничения при втората заявка.