Версия Sybase 12.5.1
Собственно вопрос, как происходит умножение??? ))
select a.table1,z.table2
from table1,table2
where a.table1=v.table2
Сначала генерируеться декартово произведение таблиц, а потом к полученной таблице применяеться условие? Или как-то подругому ???

И еще один пример:
select a.table1,z.table2
from table1,table2
where a.table1=v.table2
and b.table1 = 1234

Здесь такой же вопрос, сначала произведение генерируеться,а потом накладываеться условие
или допустим в произведение участвуют только те строки из тоблицы table1, которые удовлетворяют условию b.table1 = 1234, а потом уже идет произведение по связке a.table1=v.table2 ???

А когда в произведение участвует допустим 3 таблицы, причем количество строк в
table1 = 1 000 000 000, table2 = 1 000 000 000, table3 = 200
select ...... .....
from table1,
table2,
table3
where a.table1= v.table2
and x.table2= p.table3

Можно ли как-то построить этот запрос, чтоб он выполнялся максимально быстро.
Или его лучше разбить? Сначала перемножить table2 на table3 во временную таблицу, а потом уже полученный результат умножить на таблицу table1.

Мляяя, для результата конечно все равно )) Меня волнует вопрос производительности(скорости выполнения).
Перемножить две таблицы в которых количество записей порядка милиарда - это уже существенное время, а потом еще производить сканирование полученного произведения для применения условия WHERE - еще время.
Я так понял явно указать оптимизатору, что бы он выполнял сначала сканирование таблицы 1 для применения условия b.table1 = 1234, потом полученную усеченную таблицу умножал на таблицу 2 и потом уже применял условие a.table1=v.table2 НЕЛЬЗЯ ????
Единственный выход для этого - применять промежуточные таблицы??? Но это как-то некрасиво что ли ))

Так, напишу что получилось )))
Было такой кусок :
insert into admin_hierarchy_week
select distinct 252,
bat.battalion_name,
bat.sadmin_name,
isnull( bat.admin_name, cdr.bidl ),
isnull( bat.departament_name, '' ),
isnull( convert( int, cdr.emp_tablenum ), convert( int, ptcp.tabel )),
isnull( cdr.emp_lastname, client.descr ) + ' ' + cdr.emp_firstname,
isnull( cdr.emp_personcode, -13 ),
ptcp.mng_bank_id,
cdr.bidl,null
from
dwh_stg..fr_ptcp_hist_adr ptcp,
front_common..f_client client,
dwh_stg..cdr_employee cdr,
dwh_stg..cdr_bat_oe_week bat
where
and ptcp.bank_id = 252
and '08/20/07' between ptcp.begin_date and isnull(ptcp.end_date,'08/20/07')
and ptcp.f_manager_id = client.f_client
and convert( int, ptcp.tabel ) *= convert( int, cdr.emp_tablenum )
and datediff( mm, isnull( cdr.emp_dismissdate, '08/20/07' ), '08/20/07' ) <= 1
and cdr.bidl *= bat.bid
and cdr.emp_oe1_id <> 2094

В таблице fr_ptcp_hist_adr - 4 000 000 записей,f_client - 750 000,cdr_employee - 5000
cdr_bat_oe_week - 300 записей.
Индексы в fr_ptcp_hist_adr и f_client "все" есть )) В admin_hierarchy_week соответсвенно нету.

Этот инсерт работал больше часа.

Я этот кусок разбил на :
create table #tmp_af_adm_her
(
bank_id int NULL,
f_manager_id int NULL,
tabel int NULL,
mng_bank_id int NULL
)

insert into #tmp_af_adm_her
select distinct ptcp.bank_id,ptcp.f_manager_id,convert( int, ptcp.tabel ),mng_bank_id
from dwh_stg..fr_ptcp_hist_adr ptcp
where ptcp.bank_id = 252
and '08/20/07' between ptcp.begin_date and isnull(ptcp.end_date,'08/20/07')
плюс
insert into tmp_af_admin_hierarchy_week_2
select distinct 252,
bat.battalion_name,
bat.sadmin_name,
isnull( bat.admin_name, cdr.bidl ),
isnull( bat.departament_name, '' ),
isnull( convert( int, cdr.emp_tablenum ), convert( int, ptcp.tabel )),
isnull( cdr.emp_lastname, client.descr ) + ' ' + cdr.emp_firstname,
isnull( cdr.emp_personcode, -13 ),
ptcp.mng_bank_id,
cdr.bidl,null
from
#tmp_af_adm_her ptcp,
front_common..f_client client,
dwh_stg..cdr_employee cdr,
dwh_stg..cdr_bat_oe_week bat
where cdr.bidl *= bat.bid
and ptcp.f_manager_id = client.f_client
and convert( int, ptcp.tabel ) *= convert( int, cdr.emp_tablenum )
and datediff( mm, isnull( cdr.emp_dismissdate, '08/20/07' ), '08/20/07' ) <= 1
and cdr.emp_oe1_id <> 2094

Теперь это работает 3 минуты. Результат на лицо )))
Просто все дело в том, что после наложения условия на fr_ptcp_hist_adr в #tmp_af_adm_her попадает всего 1000 записей. Как раз 3 минуты и уходят на эту вставку. Все остальное выполняеться мгновенно.

Теперь напишите пожалуйста, как указать оптимизатору в первом варианет запроса что бы он сначала отсекал все ненужное от fr_ptcp_hist_adr, а потом уже выполнял остальные перемножения???
Версия сайбс ASE 12.5.1 . Тока напишите конкретно, а не как в общем )))

)) Ыыы. Запрос плохой )) Чем богаты, тем и рады. Буду блогадарен, если скажите, чем плохо???
И буду благодарен еще больше, если поправите ))

З.Ы. А как вы так красиво встовляете куски кода, а то у меня бардак вставился(все отступы пропали (( )

Спасибо, теперь буду хоть знать, что надо рыть инфу по использованию форсплана )).

)) СПС. Принял инфу к размышлению. На утреннюю голову сразу такой вопрос:
Практика показала, что произведение/сравнение по текстовому полю идет намного дольше, чем по числовому.
База спроектирована не мной, но уж такая фигня, что поля ptcp.tabel и cdr.emp_tablenum являеться чаровскими, но в них храниться числовая айдишка (вот такой вот нонсенс). Поэтому и стоит конверт. Казалдось, что так будет быстрее.
Второе, что я понял, лучше дистинкт убрать, а потом просто на задвоенность проверить. Но это гемор. Автоматизировать проверку задвоеености и удаление лишний строки - не так просто.

Про битвин ясно. А вот дэйтдиф чем не понравился??? Его убрать нельзя )) Условие важное ))).
З.Ы. От этого запроса уже ничего больше нехочу. Разбил его на два и теперь все летает. Хочу научиться прогать правильно )).

Этот код мне достался )) А вот пытаюсь его в божеский вид привести. СПС, щас буду размышлять над тем, что вы мне понаписали и тестить )) Еще раз огромное спасибо.

Было вот что:
а теперь
Планы запроса строить для певого смысла нет, так как с индексами уже поигрался ))
Для вторго:

QUERY PLAN FOR STATEMENT 1 (at line 1).
STEP 1
The type of query is CREATE TABLE.
QUERY PLAN FOR STATEMENT 2 (at line 11).
STEP 1
The type of query is INSERT.
The update mode is direct.
Worktable1 created, in allpages locking mode, for DISTINCT.
FROM TABLE
dwh_stg..fr_ptcp_hist_adr
ptcp
Nested iteration.
Using Clustered Index.
Index : fr_ptcp_hist_adr_bank_idx
Forward scan.
Positioning by key.
Keys are:
bank_id ASC
Using I/O Size 4 Kbytes for data pages.
With MRU Buffer Replacement Strategy for data pages.
TO TABLE
Worktable1.
STEP 2
The type of query is INSERT.
The update mode is direct.
This step involves sorting.
FROM TABLE
Worktable1.
Using GETSORTED
Table Scan.
Forward scan.
Positioning at start of table.
Using I/O Size 4 Kbytes for data pages.
With MRU Buffer Replacement Strategy for data pages.
TO TABLE
#tmp_af_adm_her
Using I/O Size 4 Kbytes for data pages.
QUERY PLAN FOR STATEMENT 3 (at line 18).
STEP 1
The type of query is INSERT.
The update mode is direct.
Worktable2 created for REFORMATTING.
FROM TABLE
dwh_stg..cdr_bat_oe
bat
Nested iteration.
Table Scan.
Forward scan.
Positioning at start of table.
Using I/O Size 4 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.
TO TABLE
Worktable2.
STEP 2
The type of query is INSERT.
The update mode is direct.
Worktable1 created, in allpages locking mode, for DISTINCT.
FROM TABLE
#tmp_af_adm_her
ptcp
Nested iteration.
Table Scan.
Forward scan.
Positioning at start of table.
Using I/O Size 4 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.
FROM TABLE
front_common..f_client
client
Nested iteration.
Using Clustered Index.
Index : pk_f_client
Forward scan.
Positioning by key.
Keys are:
f_client ASC
Using I/O Size 4 Kbytes for index leaf pages.
With LRU Buffer Replacement Strategy for index leaf pages.
Using I/O Size 4 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.
FROM TABLE
dwh_stg..cdr_employee
cdr
Nested iteration.
Table Scan.
Forward scan.
Positioning at start of table.
Using I/O Size 4 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.
FROM TABLE
Worktable2.
Nested iteration.
Using Clustered Index.
Forward scan.
Positioning by key.
Using I/O Size 4 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.
TO TABLE
Worktable1.
STEP 3
The type of query is SELECT.
This step involves sorting.
FROM TABLE
Worktable1.
Using GETSORTED
Table Scan.
Forward scan.
Positioning at start of table.
Using I/O Size 4 Kbytes for data pages.
With MRU Buffer Replacement Strategy for data pages.

Просто смысл в том, что во временную таблицу попадает всего 1000 записей примерно из огромной таблицы fr_ptcp_hist_adr.Стало работать в 20 раз быстрее и я даволен )) Видимо просто изначально первый запрос был слишком кривой.

MasterZiv
--__Александр__-- пишет:
> Практика показала, что произведение/сравнение по текстовому полю идет
> намного дольше, чем по числовому.

Ерунда полная.

> cdr.emp_tablenum являеться чаровскими, но в них храниться числовая
> айдишка (вот такой вот нонсенс). Поэтому и стоит конверт. Казалдось, что

Нет, будет медлееннее. Убирай.

> Второе, что я понял, лучше дистинкт убрать, а потом просто на
> задвоенность проверить. Но это гемор. Автоматизировать проверку
> задвоеености и удаление лишний строки - не так просто.

Да наверняка там не может быть в принципе дублирующих строк.
Просто надо знать свою БД

> Про битвин ясно. А вот дэйтдиф чем не понравился??? Его убрать нельзя ))
> Условие важное ))).

На between его что не заменить никак ?
Posted via ActualForum NNTP Server 1.4

Нефига не ерунда!!!!
select .....
from A1,A2
where A1.d1=A2.d2
Когда d1 и d2 - числовые - работает быстро. Когда d1 и d2 чаровские длинной 20 - работает дольше.
Первый вариант кода - писал не я, достался по наследству.
То что с конвертом медленне, уже понял -СПС.

Проверять данные на уникальность - времени нету. Поэтому задвоенности встречаються.
Ок, вывод ясен - функции в условиях лучше не указывать.

@begin_time = GETDATE()
@end_time = GETDATE()
DATEDIFF(ss,@begin_time,@end_time)+1)
На большой таблице не микросекунды разница)).