|
v7: Долго выполняется прямой запрос | ☑ | ||
---|---|---|---|---|
0
art_id
28.04.14
✎
10:00
|
Стали долго проводится документы, в районе минуты на прямых запросах. Томоза на получениях остатков и партий. Начал смотреть на примере остатков, в скуль передается вот такой запрос
SELECT ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура], Sum(ОстаткиТМЦОстатки.КоличествоОстаток) Количество FROM ( select rr405_vt.sp4062 as Фирма, rr405_vt.sp408 as Номенклатура, rr405_vt.sp418 as Склад, rr405_vt.sp3117 as ЦенаПрод, sum(rr405_vt.sp411) as КоличествоОстаток from ( select rg405_vt.sp4062, rg405_vt.sp408, rg405_vt.sp418, rg405_vt.sp3117, rg405_vt.sp411 from rg405 as rg405_vt (nolock) where rg405_vt.period={d '2014-03-01'} and ((rg405_vt.sp4062 = ' 2 ') AND (rg405_vt.sp418 = ' 6 ') AND (rg405_vt.sp408 IN ( SELECT DISTINCT СтрокиДокумента.sp1599 [rg405_vt.sp408 $Справочник.Номенклатура] FROM dt1611 AS СтрокиДокумента With (NOLOCK) WHERE (СтрокиДокумента.IDDOC = ' 69AFN ') ))) union all select ra405_vt.sp4062, ra405_vt.sp408, ra405_vt.sp418, ra405_vt.sp3117, case ra405_vt.debkred when 0 then ra405_vt.sp411 else -ra405_vt.sp411 end from ra405 as ra405_vt (nolock) inner join _1sjourn as j405_vt (nolock) on j405_vt.iddoc = ra405_vt.iddoc where j405_vt.date_time_iddoc > '20140401' and j405_vt.date_time_iddoc < '201404255ODW9C 69AFMЯЯЯ' and j405_vt.rf405 = 0x1 and ((ra405_vt.sp4062 = ' 2 ') AND (ra405_vt.sp418 = ' 6 ') AND (ra405_vt.sp408 IN ( SELECT DISTINCT СтрокиДокумента.sp1599 [ra405_vt.sp408 $Справочник.Номенклатура] FROM dt1611 AS СтрокиДокумента With (NOLOCK) WHERE (СтрокиДокумента.IDDOC = ' 69AFN ') ))) ) as rr405_vt group by rr405_vt.sp4062, rr405_vt.sp408, rr405_vt.sp418, rr405_vt.sp3117 having sum(rr405_vt.sp411) <> 0 ) as ОстаткиТМЦОстатки GROUP BY ОстаткиТМЦОстатки.Номенклатура Причем если убрать условие по списку номенклатуры из второго подзапроса, то выполняется за 2 сек, если оставить, то 53 сек. Подскажите что можно глянуть? Фрагментация индекса таблицы DT1611 0.01. Сам запрос SELECT DISTINCT СтрокиДокумента.sp1599 [ra405_vt.sp408 $Справочник.Номенклатура] FROM dt1611 AS СтрокиДокумента With (NOLOCK) WHERE (СтрокиДокумента.IDDOC = ' 69AFN ') формируется быстро |
|||
52
dk
28.04.14
✎
15:30
|
кто в итоге победил?
|
|||
53
Ёпрст
28.04.14
✎
15:59
|
(51) 7 секунд ? Это непростительно долго.
|
|||
54
Ёпрст
28.04.14
✎
16:02
|
регистры поди еще и не закрыты.. 7 секунд, это по останкам на складах или по партиям ?
индекс скан по какой табличке ? |
|||
55
Mikeware
28.04.14
✎
16:03
|
(54) судя по всему, ОстаткиТМЦ
|
|||
56
Ёпрст
28.04.14
✎
16:14
|
(55) там вообще всё мгновенно должно выполняться
|
|||
57
Ёпрст
28.04.14
✎
16:15
|
самая "легкая" табличка регистра
|
|||
58
Ёпрст
28.04.14
✎
16:19
|
И это, как и чем делается замер выполнения запроса ?..
|
|||
59
art_id
28.04.14
✎
19:36
|
(58) замер делается в СКЛ запросом, который выполняется в профайлере. Индекс скан по таблице _1SJourn. Если неделю назад документ проводился за секунду в базе монопольно, то сейчас стал почти минуту. Остатки ТМЦ около 6-7 секунд, Партии 10-11. Как узнать закрывается регистр или нет? По ргистру остатков быстро данные получает, а вот обороты хромают.
|
|||
60
Злопчинский
28.04.14
✎
21:42
|
(59) раньше работали в терминале, сейчас - локально...??? или м.б. посмотри как путь к базе в стартере прописан?
|
|||
61
КонецЦикла
28.04.14
✎
22:07
|
(59) Ну и что произошло за эту неделю? Перепроводили, меняли сеть, сервер, терминал-локально, ... ?
Закрываются или нет легко проверить - выгрузи итоги или отчетом универсальным посмотри Может быть надо переиндексировать, смахнуть пыль |
|||
62
art_id
29.04.14
✎
03:09
|
(60)Большая часть работает в терминале
(61)Документы проводятся каждый день массово, сервер не меняли. Реиндексация каждое воскресенье делается, но в этот раз с ошибкой вывалилась. ПОпробую попросить время запустить чтобы. |
|||
63
art_id
29.04.14
✎
03:49
|
(61)А по весу табличек регистров не смогу определить закрыт он или нет?
Где то в инете натыкался, но там для ДБФ было вроде. А как отчетом универсальным посмотреть, подскажи пжл, ато не соображу? |
|||
64
ADirks
29.04.14
✎
06:48
|
(62) Кстати, для обслуживания индексов и статистик есть такой замечательный скрипт http://infostart.ru/public/256292/
В рабочее время можно запустить его в режиме сбора статистик. Что касается незакрываемости регистров, то врядли это твой случай - тогда пухнет табличка RG, а у тебя что-то странное с RA/_1sjourn. Типа, вдруг резко увеличилось количество движений. Ещё кстати: а что там с "degree of parallellism"? оно иногда весьма неожиданный эффект даёт. |
|||
65
art_id
29.04.14
✎
07:11
|
(64)Вобщем выставил галку Быстрая обработка движений у регистров Остатки и Партии.
Переписал условие по списку номенклатуры через MetaDataWork чтобы исключить временные таблицы и джойн с журналом. В итоге запрос по остаткам выполняется 5 сек. Узкое место все также показывает Индекс скан. Максимальная степень параллелизма - 1. Скрипт скачаю, запущу, посмотрим что покажет. Только какие параметры там выставлять надо? Как на примере? |
|||
66
ADirks
29.04.14
✎
07:26
|
(65) на самом деле я наврал про проблемы с RA - расклад в процентах нормальный, в RA действительно данных больше. Ради интереса посмотрел расклад и время на тестовой базе (около 10тыс. движений в мес.) - в процентах расклад похожий, время - меньше секунды.
5 сек - это правда что-то запредельное. |
|||
67
art_id
29.04.14
✎
07:31
|
(66)Вот уже не знаю куда копать. Скрипт запущу на тестовой, посмотрю что выдаст.
|
|||
68
Ёпрст
29.04.14
✎
09:05
|
(65) индекс скан по какой табличке ?
|
|||
69
art_id
29.04.14
✎
09:22
|
(68)по таблице RA и у Остатков и у Партий
|
|||
70
Ёпрст
29.04.14
✎
10:17
|
Текст запроса сейчас какой хоть ?
|
|||
71
art_id
29.04.14
✎
10:29
|
(70)Который в профайлере или в 1С?
|
|||
72
Ёпрст
29.04.14
✎
10:35
|
lf lfdfq b njn b njn
|
|||
73
art_id
29.04.14
✎
10:38
|
ТекстЗапроса = "
|SELECT | ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура], | Sum(ОстаткиТМЦОстатки.КоличествоОстаток) Количество |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,, | (Фирма = :Фирма) | AND (Номенклатура IN (Select Val FROM #СписокНоменклатуры)) | AND (Склад = :Склад),, | Количество) AS ОстаткиТМЦОстатки |GROUP BY | ОстаткиТМЦОстатки.Номенклатура |"; |
|||
74
art_id
29.04.14
✎
10:39
|
SELECT
ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура], Sum(ОстаткиТМЦОстатки.КоличествоОстаток) Количество FROM ( select rr405_vt.sp4062 as Фирма, rr405_vt.sp408 as Номенклатура, rr405_vt.sp418 as Склад, rr405_vt.sp3117 as ЦенаПрод, sum(rr405_vt.sp411) as КоличествоОстаток from ( select rg405_vt.sp4062, rg405_vt.sp408, rg405_vt.sp418, rg405_vt.sp3117, rg405_vt.sp411 from rg405 as rg405_vt (nolock) where rg405_vt.period={d '2014-03-01'} and ((rg405_vt.sp4062 = ' 2 ') AND (rg405_vt.sp408 IN (Select Val FROM #СписокНоменклатуры))) union all select ra405_vt.sp4062, ra405_vt.sp408, ra405_vt.sp418, ra405_vt.sp3117, case ra405_vt.debkred when 0 then ra405_vt.sp411 else -ra405_vt.sp411 end from ra405 as ra405_vt (nolock) where ra405_vt.date_time_iddoc > '20140401' and ra405_vt.date_time_iddoc < '201404298FCZV4 6AIESЯЯЯ' and ((ra405_vt.sp4062 = ' 2 ') AND (ra405_vt.sp408 IN (Select Val FROM #СписокНоменклатуры)) ) ) as rr405_vt group by rr405_vt.sp4062, rr405_vt.sp408, rr405_vt.sp418, rr405_vt.sp3117 having sum(rr405_vt.sp411) <> 0 ) as ОстаткиТМЦОстатки GROUP BY ОстаткиТМЦОстатки.Номенклатура |
|||
75
Ёпрст
29.04.14
✎
10:42
|
Выкинь гроупбай из текста запроса и сумму, воткни (Номенклатура) в параметры виртуальной таблицы + условия в ВТ задай в том же порядке, что и измерения в регистре
|
|||
76
Ёпрст
29.04.14
✎
10:45
|
и.. странно, что примитив с debkred в ВТ реализован через case, а не просто через умножение.
Это, 1cpp какой хоть версии у тебя ? |
|||
77
art_id
29.04.14
✎
10:48
|
(75) не тот видимо копировал запрос, вот текущий
ТекстЗапроса = " |SELECT | ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура], | (ОстаткиТМЦОстатки.КоличествоОстаток) Количество |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,, | (Фирма = :Фирма) | AND (Номенклатура IN (Select Val FROM #СписокНоменклатуры)) | AND (Склад = :Склад) |,Номенклатура, | Количество) AS ОстаткиТМЦОстатки |"; (76)Версия DLL 2.5.0.8 |
|||
78
trad
29.04.14
✎
10:50
|
(76) debkred через case в любой версии 1cpp
|
|||
79
Ёпрст
29.04.14
✎
11:18
|
(78) странно, а чего так ?
|
|||
80
trad
29.04.14
✎
11:22
|
(79) есть существенная разница?
|
|||
81
trad
29.04.14
✎
11:25
|
еще, чтобы вместо условий
period={d '2014-03-01'} date_time_iddoc > '20140401' and date_time_iddoc < '201404298FCZV4 6AIESЯЯЯ' было что то типа: period={d '2014-04-01'} date_time_iddoc > '201404298FCZV4 6AIESЯЯЯ' and date_time_iddoc < '20140501' в модуле проведения допускается использовать ОбратныйРасчетОтТА(1) |
|||
82
Ёпрст
29.04.14
✎
11:28
|
(80) ага, религиозные убеждения :)
|
|||
83
trad
29.04.14
✎
11:34
|
я бы на месте автора воткнул быструю обработку движений по измерению Номенклатура и вернул фильтр по $ДокументСтроки
|
|||
84
Ёпрст
29.04.14
✎
11:36
|
(83) слушай, лень профайлер открывать, при указании конкретного измерения в параметрах ВТ, вт же не разворачивается в запрос, как в (74) , т.е по всем измерениям ?..
|
|||
85
Mikeware
29.04.14
✎
11:37
|
(84) ага. Там и профайлера не надо, достаточно select *
|
|||
86
trad
29.04.14
✎
11:38
|
(84) нет, не разворачивается
(74) не соответствует (77) |
|||
87
Ёпрст
29.04.14
✎
11:39
|
(86) я так и знал :)
|
|||
88
Ёпрст
29.04.14
✎
11:39
|
что одна из черепашек врёт.
|
|||
89
Ёпрст
29.04.14
✎
11:40
|
ну и про выполнение запроса в 5 секунд.. тоже не верится, не ясно, как автор делал замер.
|
|||
90
Ёпрст
29.04.14
✎
11:41
|
сдаётся, что это не время выполнения запроса, а время еще чего - например, показа тз через выбратьстроку, еще чего.. хз в общем
|
|||
91
Mikeware
29.04.14
✎
11:41
|
(90) типизация 100500 строк номенклатуры?
|
|||
92
Ёпрст
29.04.14
✎
11:45
|
(91) ну не знаю, всё равно не 5 секунд :)
|
|||
93
art_id
29.04.14
✎
11:45
|
(90)
пЗапрос = СоздатьОбъект("ODBCRecordSet"); ТекстЗапроса = " |SELECT | ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура], | (ОстаткиТМЦОстатки.КоличествоОстаток) Количество |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,, | (Фирма = :Фирма) | AND (Номенклатура IN (Select Val FROM #СписокНоменклатуры)) | AND (Склад = :Склад) |,Номенклатура, | Количество) AS ОстаткиТМЦОстатки |"; пЗапрос.УстановитьТекстовыйПараметр("КонДата", СформироватьПозициюДокумента(Конт.ТекущийДокумент(), -1)); пЗапрос.УстановитьТекстовыйПараметр("Фирма", Фирма); пЗапрос.УстановитьТекстовыйПараметр("Склад", Склад); СписокНоменклатуры = СоздатьОбъект("СписокЗначений"); Конт.ВыгрузитьТабличнуюЧасть(СписокНоменклатуры, "Номенклатура"); пЗапрос.УложитьСписокОбъектов(СписокНоменклатуры, "#СписокНоменклатуры", "Номенклатура"); пЗапрос.Отладка(1); Сообщить(ТекущееВремя()); пТЗ = пЗапрос.ВыполнитьИнструкцию(ТекстЗапроса); Сообщить(ТекущееВремя()); |
|||
94
art_id
29.04.14
✎
11:46
|
Выдает
11:44:54 SELECT ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура], (ОстаткиТМЦОстатки.КоличествоОстаток) Количество FROM ( select rr405_vt.sp408 as Номенклатура, sum(rr405_vt.sp411) as КоличествоОстаток from ( select rg405_vt.sp408, rg405_vt.sp411 from rg405 as rg405_vt (nolock) where rg405_vt.period={d '2014-03-01'} and ((rg405_vt.sp4062 = ' 2 ') AND (rg405_vt.sp408 IN (Select Val FROM #СписокНоменклатуры)) AND (rg405_vt.sp418 = ' 6 ')) union all select ra405_vt.sp408, case ra405_vt.debkred when 0 then ra405_vt.sp411 else -ra405_vt.sp411 end from ra405 as ra405_vt (nolock) where ra405_vt.date_time_iddoc > '20140401' and ra405_vt.date_time_iddoc < '201404255IQX5S 69A9KЯЯЯ' and ((ra405_vt.sp4062 = ' 2 ') AND (ra405_vt.sp408 IN (Select Val FROM #СписокНоменклатуры)) AND (ra405_vt.sp418 = ' 6 ')) ) as rr405_vt group by rr405_vt.sp408 having sum(rr405_vt.sp411) <> 0 ) as ОстаткиТМЦОстатки 11:45:01 |
|||
95
КонецЦикла
29.04.14
✎
11:47
|
_GetPerformanceCounter() точнее
Тут все может быть по-разному, т.к. кешируется А вообще посмотри план выполнения Но думаю лучше навести порядок как я писал ранее |
|||
96
trad
29.04.14
✎
11:48
|
(89)индекс-скан по индексу DATETIME на периоде в месяц при большом количестве движений может и 5 и более секунд делаться
|
|||
97
art_id
29.04.14
✎
11:54
|
(95)4 раза выполнил запрос с _GetPerformanceCounter, выполняется все дольше и дольше: 8141, 8818, 12616 и 14724
|
|||
98
Ёпрст
29.04.14
✎
11:54
|
(96) а чего скан ?
|
|||
99
Ёпрст
29.04.14
✎
11:54
|
(97) порядок измерений в регистре какой хоть ?
|
|||
100
art_id
29.04.14
✎
11:55
|
(99) Фирма, Номенклатура, Склад, ЦенаПрод
|
|||
101
Mikeware
29.04.14
✎
12:00
|
(97)чой-то у тебя неправильно. по идее, закэшироваться должно, и в ближайшее время выполняться моментально....
|
|||
102
Ёпрст
29.04.14
✎
12:01
|
Так, сколько ?
ТекстЗапроса = " |SELECT | ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура], | (ОстаткиТМЦОстатки.КоличествоОстаток) Количество |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,, | (Фирма = :Фирма) | AND (Склад = :Склад) |,Номенклатура, | Количество) AS ОстаткиТМЦОстатки | where Номенклатура IN (Select Val FROM #СписокНоменклатуры) |"; |
|||
103
Ёпрст
29.04.14
✎
12:06
|
+102 ну и совет с ОбратныйРасчетОтТА(1) сделал ?
|
|||
104
Ёпрст
29.04.14
✎
12:07
|
ну и это, воткни turbomd наконец (чтоб на лету модули править) и обнови 1cpp до последней.
|
|||
105
art_id
29.04.14
✎
12:08
|
(102)Выполнил 4 раза также: 15072, 11102, 11421, 10420
(103)Если у меня ТА на 30 число, а док на 25 это не помешает? (104)Щас база восстановится тестовая, буду там пробовать. |
|||
106
Ёпрст
29.04.14
✎
12:11
|
>>> у меня ТА на 30 число
Нахрена ты её туда задвинул ?! |
|||
107
Mikeware
29.04.14
✎
12:11
|
(105) задвинь ТА на конец года. а лучше - лет на 100....
|
|||
108
art_id
29.04.14
✎
12:12
|
(106)Иначе доки не проводятся, много документов на 23:59:59
|
|||
109
trad
29.04.14
✎
12:13
|
(106)не существенно, мы же рассматриваем проведение не актульного документа.
|
|||
110
Ёпрст
29.04.14
✎
12:15
|
(109) ? та ну ? у него щас все доки в заднем числе :) ну и шерстить ra как то не очень.. тем более, записи целого месяца.
|
|||
111
Ёпрст
29.04.14
✎
12:16
|
а так, в потоке бы проводил и привет
|
|||
112
trad
29.04.14
✎
12:16
|
(110) "у него щас все доки в заднем числе :)"
кто сказал?.. не факт |
|||
113
Ёпрст
29.04.14
✎
12:16
|
(108) зачем ты их туда задвинул ?
|
|||
114
Ёпрст
29.04.14
✎
12:17
|
(112) ну как это не факт ? ТА то он вперёд толканул, в 30 число, а проводит 25-е
|
|||
115
Ёпрст
29.04.14
✎
12:18
|
+ расчет не от ТА стоял, целый месяц напрягать ра приходится запросу.
|
|||
116
trad
29.04.14
✎
12:18
|
(111) проводил бы в потоке - не дергалась бы ra вообще - не возникло бы проблемы, не пришлось бы исследовать
|
|||
117
Ёпрст
29.04.14
✎
12:18
|
ну , точнее 25 дней :)
|
|||
118
Ёпрст
29.04.14
✎
12:18
|
(116) я за то и говорю, нахрена он та задвинул вперёд ?
:)) |
|||
119
trad
29.04.14
✎
12:19
|
(114) ааа я тебя не правильно понял
"у него щас все доки в заднем числе :" - я подумал, ты про то, что все доки 30 |
|||
120
Ёпрст
29.04.14
✎
12:19
|
А так, период 5 дней.. и можно вообще забыть, где там ТА..
|
|||
121
art_id
29.04.14
✎
12:22
|
(113)Если у текущего непроведенного документа дату поменять на 5 дней вперед, то время меняется же? Либо при записи ставить время документа?
|
|||
122
trad
29.04.14
✎
12:23
|
у мну тоже доки разрешено проводить будущей датой.
и текущее проведение всегда неактуальное живу спокойно, все проводится моментально (периодичность итогов - месяц) |
|||
123
art_id
29.04.14
✎
12:29
|
Поменять периодичность можно, но неизвестно сколько она будет обрабатывать регистр. Попробую сегодня на ночь поставлю на тестовой.
|
|||
124
Ёпрст
29.04.14
✎
12:30
|
(123) для начала, (81) и (103) сделай...
|
|||
125
art_id
29.04.14
✎
12:39
|
(124)Попробовал в обработке: 302, 298, 297, 317. Конт указал просто ссылку на документ.
Только какие могут быть последствия? |
|||
126
art_id
29.04.14
✎
12:40
|
+(125)Я только не пойму, если у меня нет итогов еще на 1 мая, как результат то корректный получается?
|
|||
127
Ёпрст
29.04.14
✎
12:43
|
(126) че ?..
|
|||
128
trad
29.04.14
✎
12:44
|
(125) "Только какие могут быть последствия?"
никаких, кроме ускорения Но замечу, что ОбратныйРасчетОтТА можно применять только в модуле проведения, либо в иной транзакции с блокировкой проведения документов |
|||
129
trad
29.04.14
✎
12:46
|
(126) итоги на начало 1 мая = итогам на конец 30 апреля. Логично же.
А итоги на конец апреля как раз таки записаны тут period={d '2014-04-01'} |
|||
130
art_id
29.04.14
✎
12:49
|
(128)Т.е. в глобальнике при проведении можно смело использовать?
(129)Не пойму, тогда зачем движения еще с 25 по 30 апреля? |
|||
131
trad
29.04.14
✎
12:49
|
art_id, sql сервер какой версии?
|
|||
132
art_id
29.04.14
✎
12:50
|
(131)2005
|
|||
133
trad
29.04.14
✎
12:52
|
(130) глобальник не причем. при проведении - да
Движения 25-30 _вычитаются_ из итогов на конец 30апр Иначе, движения 1-25 прибавляются к итогам на начало 1апр Посмотри внимательно в отладочные запросы. Обрати внимание на даты и знаки |
|||
134
trad
29.04.14
✎
12:53
|
+ на знаки в этом выражении case ra405_vt.debkred when 0 then ra405_vt.sp411 else -ra405_vt.sp411 end
|
|||
135
art_id
29.04.14
✎
12:55
|
(133)Увидел, спс
|
|||
136
Mikeware
29.04.14
✎
12:55
|
(129) только одно непонятно - почему для итогов на конец месяца выбрано первое число....
|
|||
137
Ёпрст
29.04.14
✎
12:56
|
(130)
2. останки не на ТА вычисляются как предыдущий остаток + (приход - расход до нужной даты), либо останки на ТА - движения до документа.. |
|||
138
Mikeware
29.04.14
✎
12:56
|
(134) а почему все-таки кейс, а не умножение?
|
|||
139
trad
29.04.14
✎
12:58
|
(136) наверно потому что первое во всех месяцах первое, а последнее - разное
|
|||
140
trad
29.04.14
✎
12:59
|
(138) выше сказано - религия наверно
|
|||
141
art_id
29.04.14
✎
13:00
|
(137)НЕ обратил внимание что в первом случае складываются, а во втором вычитаются.
Попробую сегодня скрипт запустить из (64), странно что ни с того ни с сего вдруг стал долго выполняться запрос. |
|||
142
Ёпрст
29.04.14
✎
13:00
|
надо бы как-нить померить скорость с кейсом и без..
|
|||
143
Mikeware
29.04.14
✎
13:01
|
(139) Ну, фактически же это остатки на начало следующего? я бы взял первое число следующего....
хотя твоя логика тоже |
|||
144
ADirks
29.04.14
✎
13:01
|
(138) это реально вопрос религии: я проверял на несколькоих миллионах записей - разница в рамках статистической погрешности.
|
|||
145
Ёпрст
29.04.14
✎
13:01
|
(141) нехрен ТА вперёд загонять.
Раньше документы в "потоке" проводились и запрос просто обращался к одной табличке - к RG.. а сейчас молотит еще и тяжелую RA |
|||
146
trad
29.04.14
✎
13:02
|
(140) другая (моя) версия, автор ВТ подсмотрел это у самих одинесовцев
|
|||
147
Ёпрст
29.04.14
✎
13:02
|
(143)ага, а что брать для периодичности 5 дней, к примеру ? :)
|
|||
148
Mikeware
29.04.14
✎
13:02
|
(144) ок, спасибо. я не проверял на больших объемах.
Хотя кейс - он читабельнее для человека, поэтому раз не быстрее - значит, правильнее. |
|||
149
Mikeware
29.04.14
✎
13:03
|
(147) убил.
|
|||
150
art_id
29.04.14
✎
13:09
|
(145)всегда ТА была на 7 дней макс вперед установлена
|
|||
151
Z1
29.04.14
✎
15:16
|
(142) ничего не выявишь.даже померить проблематично.
как бы case более правильней с точки зрения неявного преобразования типов. ну если так нравиться умножение то пиши в нем явное преобразование типов. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |