STOPKEY после PARTITION RANGE ITERATOR при динамическом partition pruning / Oracle

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Oracle [игнор отключен] [закрыт для гостей] / STOPKEY после PARTITION RANGE ITERATOR при динамическом partition pruning

3 сообщений из 3, страница 1 из 1

STOPKEY после PARTITION RANGE ITERATOR при динамическом partition pruning

#39964208

Akustik

Гость

Есть: таблица с range (ну или interval) партиционированием по дате.
Нужно найти первую строку начиная с самой поздней партиции с заданными границами по дате партиционирования.

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

create table test_pruning(d)
partition by range(d)(
 partition p1 values less than (date '2020-01-11'),
 partition p2 values less than (date '2020-01-12'),
 partition p3 values less than (date '2020-01-13'),
 partition p4 values less than (date '2020-01-14'))
as
select date '2020-01-10' from dual union all
select date '2020-01-11' from dual union all
select date '2020-01-12' from dual union all
select date '2020-01-13' from dual;
commit;

Если никаких фильтров на дату партиционирования нет, то всё хорошо - STOPKEY идёт сразу после TABLE ACCESS и до PARTITION RANGE ALL:

Код: plsql

1.
2.
3.
4.
5.

select /*+gather_plan_statistics*/*
  from (select *
          from test_pruning t
      order by d desc)
 where rownum = 1;

Что получили:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

----------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                | Name         | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | Pstart| Pstop | A-Rows |
----------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT         |              |      1 |        |       |    17 (100)|          |       |       |      1 |
|*  1 |  COUNT STOPKEY           |              |      1 |        |       |            |          |       |       |      1 |
|   2 |   PARTITION RANGE ALL    |              |      1 |      5 |    45 |    17   (6)| 00:00:01 |     4 |     1 |      1 |
|   3 |    VIEW                  |              |      1 |      5 |    45 |    17   (6)| 00:00:01 |       |       |      1 |
|*  4 |     SORT ORDER BY STOPKEY|              |      1 |      5 |    45 |    17   (6)| 00:00:01 |       |       |      1 |
|   5 |      TABLE ACCESS FULL   | TEST_PRUNING |      1 |      5 |    45 |    16   (0)| 00:00:01 |     4 |     1 |      1 |
----------------------------------------------------------------------------------------------------------------------------

Начали сканить с 4й по 1ю партицию, но просканили только одну, нашли 1 строку и закончили. Благодаря тому что STOPKEY находится под PARTITION RANGE ALL

Если задать только правую границу, то тоже всё хорошо:

Код: plsql

1.
2.
3.
4.
5.
6.

select /*+gather_plan_statistics*/*
  from (select *
          from test_pruning t
         where d <= :d_2020_01_12
      order by d desc)
 where rownum = 1;

Получили:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

-----------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                 | Name         | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | Pstart| Pstop | A-Rows |
-----------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT          |              |      1 |        |       |    17 (100)|          |       |       |      1 |
|*  1 |  COUNT STOPKEY            |              |      1 |        |       |            |          |       |       |      1 |
|   2 |   PARTITION RANGE ITERATOR|              |      1 |      5 |    45 |    17   (6)| 00:00:01 |   KEY |     1 |      1 |
|   3 |    VIEW                   |              |      1 |      5 |    45 |    17   (6)| 00:00:01 |       |       |      1 |
|*  4 |     SORT ORDER BY STOPKEY |              |      1 |      5 |    45 |    17   (6)| 00:00:01 |       |       |      1 |
|*  5 |      TABLE ACCESS FULL    | TEST_PRUNING |      1 |      5 |    45 |    16   (0)| 00:00:01 |   KEY |     1 |      1 |
-----------------------------------------------------------------------------------------------------------------------------

в общем-то, всё также, только теперь сканим не с 4й, а с вычисленной партиции, всё логично.
С заданной только левой границей всё тоже самое, всё ожидаемо.

А вот с обеими заданными границами начинаются проблемы:

Код: plsql

1.
2.
3.
4.
5.
6.
7.

select /*+gather_plan_statistics*/*
  from (select *
          from test_pruning t
         where d >= :d_2020_01_11
           and d <= :d_2020_01_12
      order by d desc)
 where rownum = 1;

и получили лажу:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.

--------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | Pstart| Pstop | A-Rows |
--------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |      1 |        |       |    17 (100)|          |       |       |      1 |
|*  1 |  COUNT STOPKEY               |              |      1 |        |       |            |          |       |       |      1 |
|   2 |   VIEW                       |              |      1 |      5 |    45 |    17   (6)| 00:00:01 |       |       |      1 |
|*  3 |    SORT ORDER BY STOPKEY     |              |      1 |      5 |    45 |    17   (6)| 00:00:01 |       |       |      1 |
|*  4 |     FILTER                   |              |      1 |        |       |            |          |       |       |      2 |
|   5 |      PARTITION RANGE ITERATOR|              |      1 |      5 |    45 |    16   (0)| 00:00:01 |   KEY |   KEY |      2 |
|*  6 |       TABLE ACCESS FULL      | TEST_PRUNING |      2 |      5 |    45 |    16   (0)| 00:00:01 |   KEY |   KEY |      2 |
--------------------------------------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   1 - filter(ROWNUM=1)
   3 - filter(ROWNUM=1)
   4 - filter(:D_2020_01_12>=:D_2020_01_11)
   6 - filter(("D">=:D_2020_01_11 AND "D"<=:D_2020_01_12))

STOPKEY теперь делается после PARTITION RANGE ITERATOR. Это приводит к тому что сканим 2 партиции, получаем 2 строки.
Не понимаю, каким образом тут мешает (и мешает ли) появившийся фильтр(4) валидиции границ (правая >= левой) - :D_2020_01_12>=:D_2020_01_11

Подобное обсуждали вот тут , а прям конкретно эта проблема вот там (предложили написать d+0 >=, но это ерунда потому что ломает прунинг по левой границе).
Что делать, неясно. Есть мысли?

P.S. Проблема только с биндами - с литералами всё прекрасно.
P.P.S. Тесткейс упростил максимально (в сравнении с бизнес задачей). Возможно, даже слишком - усложню, если нужно.
P.P.P.S. 11.2, 19c - одинаково плохо.

...

Рейтинг:

0 / 0

29.05.2020, 18:22

| Ответить | Цитировать | Написать

STOPKEY после PARTITION RANGE ITERATOR при динамическом partition pruning

#39964255

Alexander Anokhin

Гость

На мой взгляд это баг. Оптимизатор не видит, что в случае KEY/KEY партиции в PARTITION RANGE ITERATOR будут сканироваться по порядку, согласно сортировке.

Workarounds:

Код: plsql

_optimizer_filter_pushdown = false

или

Код: plsql

_optimizer_generate_transitive_pred = false

в сессии или хинтом, например,

Код: plsql

/*+ opt_param('_optimizer_filter_pushdown', 'false') */

Либо можно создать локальный индекс on TEST_PRUNING(d), чтобы вообще от сортировки избавиться.

...

Рейтинг:

0 / 0

29.05.2020, 22:58

| Ответить | Цитировать | Написать

STOPKEY после PARTITION RANGE ITERATOR при динамическом partition pruning

#39964262

Akustik

Гость

Alexander Anokhin,

_optimizer_filter_pushdown помог, спасибо.
фильтр на границы пропал и STOPKEY вернулся на место. пойду почитаю, что это такое.

...

Рейтинг:

0 / 0

29.05.2020, 23:25

| Ответить | Цитировать | Написать

3 сообщений из 3, страница 1 из 1

Форумы / Oracle [игнор отключен] [закрыт для гостей] / STOPKEY после PARTITION RANGE ITERATOR при динамическом partition pruning

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=52&fpage=45&tid=1881207]:	0ms
get settings:	9ms
get forum list:	14ms
check forum access:	4ms
check topic access:	4ms
track hit:	45ms
get topic data:	9ms
get forum data:	2ms
get page messages:	39ms
get tp. blocked users:	2ms
others:	20ms

total:	148ms