I ran the program a number of times in a 4.7 environment with DB2 databases...
The following statement:
Code:
SELECT bukrs belnr gjahr
FROM bkpf
INTO TABLE bkpf_int
WHERE bukrs IN s_bukrs
AND belnr IN s_belnr
AND gjahr EQ p_gjahr.
Is far less efficient than (Намного менее эффективно чем):
Code:
SELECT t001~bukrs bkpf~belnr bkpf~gjahr
FROM bkpf
INNER JOIN t001 ON
t001~bukrs EQ bkpf~bukrs
INTO TABLE bkpf_int
WHERE t001~bukrs IN s_bukrs
AND bkpf~belnr IN s_belnr
AND bkpf~gjahr EQ p_gjahr.
when a range of company codes is used.
Для Oracle 10 это не так: первый SELECT в среднем быстрее на 10-15%... Особенности СУБД, диспетчера запросов? _________________ ABAP/4 You
Age: 48 Joined: 25 Jan 2008 Posts: 580 Location: Москва
Posted: Thu Mar 03, 2011 4:17 pm Post subject:
По-моему просто напутали.
Как SELECT по ОДНОЙ таблице может выполняться быстрее, чем по ДВУМ? Тем более одна из которых буферизована
Есть конечно сложные случаи, но в целом я руководствуюсь нотами 766349 (FAQ: Oracle SQL optimization) и 825653 - Oracle: Common misconceptions . _________________ С уважением,
Удав.
Age: 47 Joined: 14 Nov 2008 Posts: 300 Location: Russia
Posted: Thu Mar 03, 2011 11:40 pm Post subject:
Коллеги, приношу свои извинения, похоже я зря ворчал на Седого... Мне кажется, я понял, как индус получил такой результат. Ещё не мерял, но возможно если задать в по БЕ интервал IBT0000ZZZZ при больших объемах данных, то как раз и получим "Is far less efficient than"...
UPD: правда вот на чуть более 9 тыс. записей доступной на данный момент BKPF ничего подобного, естественно, не наблюдается. _________________ ABAP/4 You
Age: 48 Joined: 25 Jan 2008 Posts: 580 Location: Москва
Posted: Fri Mar 04, 2011 10:31 am Post subject:
Dmitriy wrote:
Мне кажется, я понял, как индус получил такой результат. Ещё не мерял, но возможно если задать в по БЕ интервал IBT0000ZZZZ при больших объемах данных, то как раз и получим "Is far less efficient than"...
Интересно, а какой вообще смысл в выборке по большому количеству БЕ? Обычно для таких целей хранилище данных используется
Вот если бы речь шла о документах материала и заводах (WERKS), тогда лучше бы было разбить SELECT с IN на несколько с условием равенства (но опять же, не использовать INNER JOIN - это будет медленнее). _________________ С уважением,
Удав.
Age: 47 Joined: 14 Nov 2008 Posts: 300 Location: Russia
Posted: Fri Mar 04, 2011 5:59 pm Post subject:
Удав wrote:
но опять же, не использовать INNER JOIN - это будет медленнее
Мне одному кажется, или?..
Естественно, у меня не BKPF, про неё я бы и не стал спрашивать, тем более в примере выбор по ключам. Просто на определенном этапе, оптимизируя логистическую коммерческую, блин, тайну , в матчасти форума увидел это и несколько рановато пришли нехорошие мысли о форуме "Трудоустройство"...
admin wrote:
Коллеги, у вас у всех есть права на изменение записей в справочниках. Не стесняйтесь вносить изменения, если видите ошибки
Буду разбивать на несколько выборок при участии VBFA и EKBE. Результат и так уже получен неплохой, выложить его можно будет несколько позже. Подавляющее число примеров на эту тему в сети уже просмотрены, нужные индексы сделаны, всем спасибо. _________________ ABAP/4 You
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
All product names are trademarks of their respective companies. SAPNET.RU websites are in no way affiliated with SAP AG. SAP, SAP R/3, R/3 software, mySAP, ABAP, BAPI, xApps, SAP NetWeaver and any other are registered trademarks of SAP AG. Every effort is made to ensure content integrity. Use information on this site at your own risk.
