Connect by — интересный случай

[Mingun]

Еще бы написали, что хотели получить от примера запроса. Потому что по условию connect by вы хотите получить для каждой записи до миллиона порожденных. В том числе для каждой порожденной. Тут экспоненциальное количество строк. Так что предупреждать, наверное, стоит от условий, отличных от = в connect by (каждый or дает +1 к экспоненте, а условие < X все равно что =1 or =2 or ... or =X-1).

[drema201]

Добрый день,
Намеренно не стал рассматривать разнообразные случаи, возможно можно и с "=" получить экспоненциальную сложность (ну например данные таковы что на каждом шаге кол-во данных подпадающих под условие равенства удваивается/утраивается ...) .

В чём я вижу "примечательность" этого случая.

1. Это пример чисто CPU нагрузки, фактически без потребления IO или RAM(PGA).

2. Это демонстрация того что примитивное понимание исполнения плана, а именно выполняется полностью сначала один шаг, затем переходим к следующему - не всегда верно.

[xtender]

Как-то я совсем не понял, а зачем был нужен запрос, который в принципе не имеет условий останова?
Так-то можно и упростить:

select distinct 1 from dual connect by nocycle 1=1;

Plan hash value: 1782049888

---------------------------------------------------------------------------------------
| Id  | Operation                              | Name | Rows  | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                       |      |     1 |     3  (34)| 00:00:01 |
|   1 |  SORT UNIQUE NOSORT                    |      |     1 |     3  (34)| 00:00:01 |
|*  2 |   CONNECT BY WITHOUT FILTERING (UNIQUE)|      |       |            |          |
|   3 |    FAST DUAL                           |      |     1 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------------------

Outline Data
-------------

  /*+
      BEGIN_OUTLINE_DATA
      CONNECT_BY_COMBINE_SW(@"SEL$00EF6464")
      NO_CONNECT_BY_FILTERING(@"SEL$00EF6464")
      OUTLINE(@"SEL$1")
      CONNECT_BY_ELIM_DUPS(@"SEL$1")
      OUTLINE_LEAF(@"SEL$00EF6464")
      ALL_ROWS
      DB_VERSION('19.1.0')
      OPTIMIZER_FEATURES_ENABLE('19.1.0')
      IGNORE_OPTIM_EMBEDDED_HINTS
      END_OUTLINE_DATA
  */

А про чтение планов согласен, чего стоит только это вечное заблуждение про чтение планов "снизу-вверх" - даже тут: https://habr.com/en/companies/rostelecom/articles/754074/
После обсуждения в телеграмме, решил даже скомпилировать маленькую заметку про чтение планов на основе своих старых комментов на sql.ru: https://xtender.github.io/plan/

[drema201]

Привет Саян!

Согласен можно было и попроще пример создать, синтетику писал по горячим следам и публиковал в своём блоге, а это уже перевод (не стал переделывать).

По поводу зачем : это не просто "бесконечный" запрос, а бесконечный запрос который не потребляет ничего кроме CPU и не падает. Можно использовать например для исследования честности CPU scheduling'a для resource manager'a и т.п.