Комментарии 7
Позвольте спросить, так почему CPU на БД был под 100%? Что было не так с выборкой?
Хана попыталась выполнить два подзапрос одновременно или что? Можно узнать план первого примера, что в нём оказалось дорогим?
Извините за 1000 вопросов.
Тут напрашивается выбрать сразу все явные lt_bkpf-awkey. Потом уже в цикле по et_docs_reg_material почистить записи где belnr <> lt_bkpf-belnr
А оптимизатор запросов почему не способен это делать сам, если уж это такая формальная замена?
За Пациент № 2: я бы расстреливал на месте. Потому что если этот запрос что-то не выберет, то заколебешься искать почему. Придется весь запрос вручную по кусочкам проверять
для пациента 2 в HANA есть CDS MMIM_*.
Их смысл: использованием единой MATDOC напрямую (по факту MSEG - это ракурс над MATDOC).
MMIM_MATDOCCANCDOCFLOW - показ признака cancelled (через него можно отфильтровать (не)сторно)
MMIM_MATDOCPURORDDOCFLOW - история заказа на поставу
MMIM_MATDOCDELLIVDOCFLOW - Закупочный поток с поставкой
НО: такая теория может "разбиться" о какой-нибудь камень настройки или внезапно вставленный exit. Но посмотреть стоит.
[ABAP] Некоторые нюансы использования FOR ALL ENTRIES