ReSQL.ru
     
powered by simpleCommunicator - 2.0.56     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Informix [игнор отключен] [закрыт для гостей] / Проблема с substr?
51 сообщений из 51, показаны все 3 страниц
  все  
Проблема с substr?
    #35588497
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
Помогите разобрать с проблемой!
запрос:
Код: plaintext
1.
2.
3.
4.
5.
6.
select dmfo, dacc, cmfo, cacc, amountuak
from vpayord
where
substr(cacc, 1 , 4 ) in ( 6010 , 6011 , 6012 , 6013 , 6014 , 6015 , 6016 , 6017 , 6018 )
and cmfo=config_getkey('MFO','COMMON')
and dtend between MDY( 3 , 1 , 2008 ) and MDY( 3 , 31 , 2008 )
отрабатывает за 4 минуты. Но, если заменить substr(cacc,1,4) на cacc[1,4], т.е.
Код: plaintext
1.
2.
3.
4.
5.
6.
select dmfo, dacc, cmfo, cacc, amountuak
from vpayord
where
cacc[ 1 , 4 ] in ( 6010 , 6011 , 6012 , 6013 , 6014 , 6015 , 6016 , 6017 , 6018 )
and cmfo=config_getkey('MFO','COMMON')
and dtend between MDY( 3 , 1 , 2008 ) and MDY( 3 , 31 , 2008 )
то выборка идет 3-4 секунды. В чем может быть проблема?
...
Рейтинг: 0 / 0
10.10.2008, 15:52
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35588535
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
Версия базы - 10. Тип поля cacc - varchar.
...
Рейтинг: 0 / 0
10.10.2008, 16:00
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35588551
Ikir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ikir
Участник
Кажется здесь уже такое было.
Попробуйте
substr(cacc,1,4) in ('6010','6011','6012','6013','6014','6015','6016','6017','6018')
...
Рейтинг: 0 / 0
10.10.2008, 16:05
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35588611
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
На сайте такой проблемы не нашел. Пробовал с кавычками - разницы никакой.
...
Рейтинг: 0 / 0
10.10.2008, 16:21
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35588629
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
2face
...
отрабатывает за 4 минуты. Но, если заменить substr(cacc,1,4) на cacc[1,4], т.е.
...
то выборка идет 3-4 секунды. В чем может быть проблема?
А можно взглянуть на планы запросов ?
...
Рейтинг: 0 / 0
10.10.2008, 16:28
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35588653
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
vasilis
А можно взглянуть на планы запросов ?
Извините, а что именно вы хотите увидеть?
...
Рейтинг: 0 / 0
10.10.2008, 16:35
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35588659
Фотография Тан
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тан
Участник
может есть индекс по полю cacc?
может cacc[1,4] его использует, а substr(cacc,1,4) - нет
...
Рейтинг: 0 / 0
10.10.2008, 16:36
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35588671
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
Есть два индекса по полям, одно из которых сасс.
...
Рейтинг: 0 / 0
10.10.2008, 16:39
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35588697
Фотография Тан
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тан
Участник
2faceЕсть два индекса по полям, одно из которых сасс.
чтобы понять, используется ли индекс, надо посмотреть план запроса
...
Рейтинг: 0 / 0
10.10.2008, 16:48
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35588713
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
С sql я мало работал, а с informix'ом еще меньше. Подскажите как мне посмотреть план запроса.
...
Рейтинг: 0 / 0
10.10.2008, 16:52
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35588730
Фотография Тан
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тан
Участник
2faceС sql я мало работал, а с informix'ом еще меньше. Подскажите как мне посмотреть план запроса.
Код: plaintext
1.
2.
3.
4.
5.
select {+ Explain} dmfo, dacc, cmfo, cacc, amountuak
from vpayord
where substr(cacc, 1 , 4 ) in ( 6010 , 6011 , 6012 , 6013 , 6014 , 6015 , 6016 , 6017 , 6018 )
and cmfo=config_getkey('MFO','COMMON')
and dtend between MDY( 3 , 1 , 2008 ) and MDY( 3 , 31 , 2008 )
на сервере в домашнем каталоге пользователя появится файл sqexplain.out.
в нем будет план запроса.
какая версия Informix у вас?
...
Рейтинг: 0 / 0
10.10.2008, 16:57
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35588736
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
Как говорят наши айтишники - 9.5 или 10.
...
Рейтинг: 0 / 0
10.10.2008, 17:00
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35588767
Фотография Тан
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тан
Участник
2faceКак говорят наши айтишники - 9.5 или 10.
значит у вас поддерживаются директивы оптимизатора, {+ Explain} будет работать
...
Рейтинг: 0 / 0
10.10.2008, 17:15
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35588786
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
QUERY:
------
select {+ Explain} dmfo, dacc, cmfo, cacc, amountuak
from vpayord
where
substr(cacc,1,4) in ('6010','6011','6012','6013','6014','6015','6016','6017','6018')
and cmfo=config_getkey('MFO','COMMON')
and status in ('+','G')
and dtend between MDY(3,1,2008) and MDY(3,31,2008)

DIRECTIVES FOLLOWED:
EXPLAIN
DIRECTIVES NOT FOLLOWED:

Estimated Cost: 341
Estimated # of Rows Returned: 14

1) informix.payord: INDEX PATH

Filters: ((informix.payord.status IN ('+' , 'G' )AND SUBSTR (informix.payord.cacc , 1 , 4 ) IN ('6010' , '6011' , '6012' , '6013' , '6014' , '6015' , '6016' , '6017' , '6018' )) AND ((EXISTS <subquery> OR EXISTS <subquery> ) OR EXISTS <subquery> ) )

(1) Index Keys: cmfo cacc currency dtend (Key-First) (Serial, fragments: ALL)
Lower Index Filter: informix.payord.cmfo = informix.config_getkey('MFO' ,'COMMON' )
Index Key Filters: (informix.payord.dtend >= 01/03/2008 ) AND
(informix.payord.dtend <= 31/03/2008 )

Subquery:
---------
Estimated Cost: 1
Estimated # of Rows Returned: 1

1) informix.x1: INDEX PATH

(1) Index Keys: iduser acc_mask (Key-Only) (Serial, fragments: ALL)
(fragments might be eliminated at runtime because filter contains
runtime constants)
Lower Index Filter: (informix.x1.acc_mask = 1 AND informix.x1.iduser = USER )
Index Key Filters: ((informix.x1.acc_mask = 1 OR (informix.x1.acc_mask = 2 AND informix.payord.dacclead IS NULL ) ) )

(2) Index Keys: iduser acc_mask (Key-Only) (Serial, fragments: ALL)
(fragments might be eliminated at runtime because filter contains
runtime constants)
Lower Index Filter: (informix.x1.acc_mask = 2 AND informix.x1.iduser = USER )
Index Key Filters: ((informix.x1.acc_mask = 1 OR (informix.x1.acc_mask = 2 AND informix.payord.dacclead IS NULL ) ) )

UDRs in query:
--------------
UDR id : 480
UDR name: config_getkey

Subquery:
---------
Estimated Cost: 6
Estimated # of Rows Returned: 1

1) informix.x5: INDEX PATH

(1) Index Keys: idpayord (Serial, fragments: ALL)
Lower Index Filter: informix.x5.idpayord = informix.payord.idpayord

2) informix.x4: INDEX PATH

(1) Index Keys: iduser acc_mask (Key-Only) (Serial, fragments: ALL)
(fragments might be eliminated at runtime because filter contains
runtime constants)
Lower Index Filter: (informix.x4.acc_mask = informix.x5.access_code AND informix.x4.iduser = USER )
NESTED LOOP JOIN

UDRs in query:
--------------
UDR id : 480
UDR name: config_getkey

Subquery:
---------
Estimated Cost: 13
Estimated # of Rows Returned: 1

1) informix.x2: INDEX PATH

(1) Index Keys: idacc (Serial, fragments: ALL)
Lower Index Filter: informix.x2.idacc = informix.payord.dacclead

(2) Index Keys: idacc (Serial, fragments: ALL)
Lower Index Filter: informix.x2.idacc = informix.payord.cacclead

2) informix.x3: INDEX PATH

(1) Index Keys: iduser acc_mask (Key-Only) (Serial, fragments: ALL)
(fragments might be eliminated at runtime because filter contains
runtime constants)
Lower Index Filter: (informix.x2.access_code = informix.x3.acc_mask AND informix.x3.iduser = USER )
NESTED LOOP JOIN

UDRs in query:
--------------
UDR id : 480
UDR name: config_getkey

UDRs in query:
--------------
UDR id : 480
UDR name: config_getkey
...
Рейтинг: 0 / 0
10.10.2008, 17:23
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35588817
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
Кто-нибудь может мне объяснить, как по плану запроса определить причину моей проблемы.
...
Рейтинг: 0 / 0
10.10.2008, 17:46
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35588822
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
2faceКто-нибудь может мне объяснить, как по плану запроса определить причину моей проблемы.а план запроса cacc[1,4] in где?
...
Рейтинг: 0 / 0
10.10.2008, 17:49
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35588840
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
select {+ Explain} dmfo, dacc, cmfo, cacc, amountuak
from vpayord
where
cacc[1,4] in (6010,6011,6012,6013,6014,6015,6016,6017,6018)
--substr(cacc,1,4) in ('6010','6011','6012','6013','6014','6015','6016','6017','6018')
and cmfo=config_getkey('MFO','COMMON')
and status in ('+','G')
and dtend between MDY(3,1,2008) and MDY(3,31,2008)

DIRECTIVES FOLLOWED:
EXPLAIN
DIRECTIVES NOT FOLLOWED:

Estimated Cost: 21
Estimated # of Rows Returned: 1

1) informix.payord: INDEX PATH

Filters: (informix.payord.status IN ('+' , 'G' )AND ((EXISTS <subquery> OR EXISTS <subquery> ) OR EXISTS <subquery> ) )

(1) Index Keys: cmfo cacc currency dtend (Key-First) (Serial, fragments: ALL)
Lower Index Filter: (informix.payord.cacc[1,4] = '6010' AND informix.payord.cmfo = informix.config_getkey('MFO' ,'COMMON' ))
Index Key Filters: (informix.payord.dtend >= 01/03/2008 ) AND
(informix.payord.dtend <= 31/03/2008 )

(2) Index Keys: cmfo cacc currency dtend (Key-First) (Serial, fragments: ALL)
Lower Index Filter: (informix.payord.cacc[1,4] = '6011' AND informix.payord.cmfo = informix.config_getkey('MFO' ,'COMMON' ))
Index Key Filters: (informix.payord.dtend >= 01/03/2008 ) AND
(informix.payord.dtend <= 31/03/2008 )

(3) Index Keys: cmfo cacc currency dtend (Key-First) (Serial, fragments: ALL)
Lower Index Filter: (informix.payord.cacc[1,4] = '6012' AND informix.payord.cmfo = informix.config_getkey('MFO' ,'COMMON' ))
Index Key Filters: (informix.payord.dtend >= 01/03/2008 ) AND
(informix.payord.dtend <= 31/03/2008 )

(4) Index Keys: cmfo cacc currency dtend (Key-First) (Serial, fragments: ALL)
Lower Index Filter: (informix.payord.cacc[1,4] = '6013' AND informix.payord.cmfo = informix.config_getkey('MFO' ,'COMMON' ))
Index Key Filters: (informix.payord.dtend >= 01/03/2008 ) AND
(informix.payord.dtend <= 31/03/2008 )

(5) Index Keys: cmfo cacc currency dtend (Key-First) (Serial, fragments: ALL)
Lower Index Filter: (informix.payord.cacc[1,4] = '6014' AND informix.payord.cmfo = informix.config_getkey('MFO' ,'COMMON' ))
Index Key Filters: (informix.payord.dtend >= 01/03/2008 ) AND
(informix.payord.dtend <= 31/03/2008 )

(6) Index Keys: cmfo cacc currency dtend (Key-First) (Serial, fragments: ALL)
Lower Index Filter: (informix.payord.cacc[1,4] = '6015' AND informix.payord.cmfo = informix.config_getkey('MFO' ,'COMMON' ))
Index Key Filters: (informix.payord.dtend >= 01/03/2008 ) AND
(informix.payord.dtend <= 31/03/2008 )

(7) Index Keys: cmfo cacc currency dtend (Key-First) (Serial, fragments: ALL)
Lower Index Filter: (informix.payord.cacc[1,4] = '6016' AND informix.payord.cmfo = informix.config_getkey('MFO' ,'COMMON' ))
Index Key Filters: (informix.payord.dtend >= 01/03/2008 ) AND
(informix.payord.dtend <= 31/03/2008 )

(8) Index Keys: cmfo cacc currency dtend (Key-First) (Serial, fragments: ALL)
Lower Index Filter: (informix.payord.cacc[1,4] = '6017' AND informix.payord.cmfo = informix.config_getkey('MFO' ,'COMMON' ))
Index Key Filters: (informix.payord.dtend >= 01/03/2008 ) AND
(informix.payord.dtend <= 31/03/2008 )

(9) Index Keys: cmfo cacc currency dtend (Key-First) (Serial, fragments: ALL)
Lower Index Filter: (informix.payord.cacc[1,4] = '6018' AND informix.payord.cmfo = informix.config_getkey('MFO' ,'COMMON' ))
Index Key Filters: (informix.payord.dtend >= 01/03/2008 ) AND
(informix.payord.dtend <= 31/03/2008 )

Subquery:
---------
Estimated Cost: 1
Estimated # of Rows Returned: 1

1) informix.x1: INDEX PATH

(1) Index Keys: iduser acc_mask (Key-Only) (Serial, fragments: ALL)
(fragments might be eliminated at runtime because filter contains
runtime constants)
Lower Index Filter: (informix.x1.acc_mask = 1 AND informix.x1.iduser = USER )
Index Key Filters: ((informix.x1.acc_mask = 1 OR (informix.x1.acc_mask = 2 AND informix.payord.dacclead IS NULL ) ) )

(2) Index Keys: iduser acc_mask (Key-Only) (Serial, fragments: ALL)
(fragments might be eliminated at runtime because filter contains
runtime constants)
Lower Index Filter: (informix.x1.acc_mask = 2 AND informix.x1.iduser = USER )
Index Key Filters: ((informix.x1.acc_mask = 1 OR (informix.x1.acc_mask = 2 AND informix.payord.dacclead IS NULL ) ) )

UDRs in query:
--------------
UDR id : 480
UDR name: config_getkey

Subquery:
---------
Estimated Cost: 6
Estimated # of Rows Returned: 1

1) informix.x5: INDEX PATH

(1) Index Keys: idpayord (Serial, fragments: ALL)
Lower Index Filter: informix.x5.idpayord = informix.payord.idpayord

2) informix.x4: INDEX PATH

(1) Index Keys: iduser acc_mask (Key-Only) (Serial, fragments: ALL)
(fragments might be eliminated at runtime because filter contains
runtime constants)
Lower Index Filter: (informix.x4.acc_mask = informix.x5.access_code AND informix.x4.iduser = USER )
NESTED LOOP JOIN

UDRs in query:
--------------
UDR id : 480
UDR name: config_getkey

Subquery:
---------
Estimated Cost: 13
Estimated # of Rows Returned: 1

1) informix.x2: INDEX PATH

(1) Index Keys: idacc (Serial, fragments: ALL)
Lower Index Filter: informix.x2.idacc = informix.payord.dacclead

(2) Index Keys: idacc (Serial, fragments: ALL)
Lower Index Filter: informix.x2.idacc = informix.payord.cacclead

2) informix.x3: INDEX PATH

(1) Index Keys: iduser acc_mask (Key-Only) (Serial, fragments: ALL)
(fragments might be eliminated at runtime because filter contains
runtime constants)
Lower Index Filter: (informix.x2.access_code = informix.x3.acc_mask AND informix.x3.iduser = USER )
NESTED LOOP JOIN

UDRs in query:
--------------
UDR id : 480
UDR name: config_getkey

UDRs in query:
--------------
UDR id : 480
UDR name: config_getkey
...
Рейтинг: 0 / 0
10.10.2008, 17:57
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35588851
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
Судя по этим файлам substr не использует индекс. А почему?
...
Рейтинг: 0 / 0
10.10.2008, 18:01
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35588875
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
2faceСудя по этим файлам substr не использует индекс. А почему?потому что это функция, все субд так делают. Нужен функуциональный индекс substr(cacc,1,4)
вообще я думаю что надо начинать с индекса по dtend (between MDY(3,1,2008) and MDY(3,31,2008)) если нет индексов фрагментированных по dtend.
...
Рейтинг: 0 / 0
10.10.2008, 18:09
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35590602
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Daugava
Участник
Конкретно для данного случая правильнее было бы написать
cacc LIKE '601%'

6019 счета все равно нет, ну а если появится, то наверняка потребуется. Я в таких случаях предпочитаю выносить все в настроечную табличку.
Кстати, если это процедура, то имеет смысл использовать просто payord, вьюха все таки тяжелее и для разных пользователей будет выдавать разные результаты, в зависимости от их доступов.
...
Рейтинг: 0 / 0
13.10.2008, 10:17
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35590674
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
Таблицу payord я не могу использовать, т.к. наши айтишники не рекомендуют мне этого делать. Мне просто очень интересно, почему substr так убого работает. До этого работал с ораклом и там все было нормально, даже при работе с таблицами с большим количеством записей.
...
Рейтинг: 0 / 0
13.10.2008, 10:41
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35590727
zaiets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zaiets
Гость
ну работает оно так - ниче не поделаешь.
Типичный вопрос ораклистов - почему не так как в оракле?
Ну реализовали в информикс вот таким макаром.

Дао прав по поводу лайк - тогда тоже берется индекс и все фильтры идут по индексу.
Estimated Cost: 437
Estimated # of Rows Returned: 649

1) informix.payord: INDEX PATH

(1) Index Keys: cmfo cacc currency dtend (Key-First) (Serial, fragments: ALL)
Lower Index Filter: (informix.payord.cmfo = informix.config_getkey('MFO' ,'COMMON' )AND informix.payord.cacc LIKE '601
%' )
Index Key Filters: (informix.payord.dtend >= 01/03/2008 ) AND
(informix.payord.dtend <= 31/10/2008 )

От того - представление это или нет - план для указанного фильтра не изменяется(я сделал для таблицы).

А собственно почему - Денис уже ответил.
Хотя, в данном случае было бы логично чтобы фильтр substr, если нчинается с первого символа, ганладывался на индекс.

Ну а если вы считаете что это неправильно - делайте запрос в IBM и настаивайте.
Как оформить запрос - думаю ваш разработчик вам поможет.
...
Рейтинг: 0 / 0
13.10.2008, 11:05
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35590739
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
2faceДо этого работал с ораклом и там все было нормально, даже при работе с таблицами с большим количеством записей.В этом месте информикс лучше оракла в несколько раз.
...
Рейтинг: 0 / 0
13.10.2008, 11:10
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35590767
Фотография Евгений Фадеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Евгений Фадеев
Участник
Журавлев Денис2faceДо этого работал с ораклом и там все было нормально, даже при работе с таблицами с большим количеством записей.В этом месте информикс лучше оракла в несколько раз.Речь про форум или про большие таблицы?
Если первое - то не в несколько раз, а в принципе. Если про второе - спорно :))
...
Рейтинг: 0 / 0
13.10.2008, 11:22
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35590787
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Евгений ФадеевЖуравлев Денис2faceДо этого работал с ораклом и там все было нормально, даже при работе с таблицами с большим количеством записей.В этом месте информикс лучше оракла в несколько раз.Речь про форум или про большие таблицы?
Если первое - то не в несколько раз, а в принципе. Если про второе - спорно :))про where substr(field)=

http://dil.livejournal.com/712512.html#t4415296
...
Рейтинг: 0 / 0
13.10.2008, 11:28
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35590833
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
В принципе, я получил ответ на свой вопрос. Всем спасибо за помощь и пояснения.
...
Рейтинг: 0 / 0
13.10.2008, 11:41
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35590969
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GVF112GVF
Гость
Евгений ФадеевЖуравлев Денис2faceДо этого работал с ораклом и там все было нормально, даже при работе с таблицами с большим количеством записей.В этом месте информикс лучше оракла в несколько раз.Речь про форум или про большие таблицы?
Если первое - то не в несколько раз, а в принципе. Если про второе - спорно :))

Если Вас не устраивает функциональность substr или поиск по LIKE - тогда
можно использовать технологию DataBlade - IBM INFORMIX EXCALIBUR TEXT SEARCH DATABLADE MODULE
или бесплатный поисковый datablade для версии 11.x

С уважением,
Вадим
...
Рейтинг: 0 / 0
13.10.2008, 12:28
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35591042
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Внимательно посмотрел (дошли руки)

1 запрос substr

(1) Index Keys: cmfo cacc currency dtend (Key-First) (Serial, fragments: ALL)
Lower Index Filter: informix.payord.cmfo = informix.config_getkey('MFO' ,'COMMON' )
Index Key Filters: (informix.payord.dtend >= 01/03/2008 ) AND
(informix.payord.dtend <= 31/03/2008 )

2 запрос

(1) Index Keys: cmfo cacc currency dtend (Key-First) (Serial, fragments: ALL)
Lower Index Filter: (informix.payord.cacc[1,4] = '6010' AND informix.payord.cmfo = informix.config_getkey('MFO' ,'COMMON' ))
Index Key Filters: (informix.payord.dtend >= 01/03/2008 ) AND
(informix.payord.dtend <= 31/03/2008 )

имеем индекс --- cmfo cacc currency dtend безумие, предиката с currency вообще в запросе нет, значит сканируется часть индекса лишняя. Т.е. запрос потенциально можно ускорить еще и еще, если сделать "правильный" индекс или правильно фрагментировать существующий индескс.
...
Рейтинг: 0 / 0
13.10.2008, 12:57
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35591224
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
Индексы в таблицах создала программерская контора, которая написала "замечательную" АБС Profix. Айтишники ничего исправлять или добавлять не будут.
...
Рейтинг: 0 / 0
13.10.2008, 13:57
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35591295
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
2faceИндексы в таблицах создала программерская контора, которая написала "замечательную" АБС Profix. Айтишники ничего исправлять или добавлять не будут.а фиг ли вы тогда запросы сами пишите? Естественно они работают плохо.
...
Рейтинг: 0 / 0
13.10.2008, 14:22
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35591865
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
База создана под банковскую систему профикс. Соответственно под их потребности, в плане построения отчетов и вывода информации. Но тех возможностей, которые предоставляет профикс, недостаточно. Вот и приходится мне писать различные выборки. До этого я работал с ораклом и там изначально была правильно спроектированная база. Вот поэтому я и задал вопрос, чтобы выяснить в чем проблема: информиксе или в структуре базы. Выяснилось, что в структуре.
...
Рейтинг: 0 / 0
13.10.2008, 17:21
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35591875
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Daugava
Участник
Они это пишут, поскольку им дали такую возможность. Ничего зазорного в этом нет, в крупнейшем мировом Банке (вернее в его маленькой украинской дочке) целая плеяда главбухов этим в Экселе балуется уже лет 10.

Кстати насчет совета по currency, рекомендую прислушаться и явно указать, поскольку по счетам доходов операций с валютой отличной от 980 все равно не происходит.
...
Рейтинг: 0 / 0
13.10.2008, 17:24
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35591905
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Daugava
Участник
Папрашу птичку, а именно структуру ProFIX/ODB не пенять. Пеняйте на свои запросы и не знание особенностей системы.

Я ее (структуру) не видел лет так 6, но судя по вашим запросам она не сильно изменилась. Из всех банковских систем, которые я видел (включая с десяток западных и десятка два украинских) - лучшая.
...
Рейтинг: 0 / 0
13.10.2008, 17:33
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35591968
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Daugava Я ее (структуру) не видел лет так 6, но судя по вашим запросам она не сильно изменилась. Из всех банковских систем, которые я видел (включая с десяток западных и десятка два украинских) - лучшая.

substr(cacc,1,4) in (6010,6011,6012,6013,6014,6015,6016,6017,6018)

номер счета протаскивать в таблицу проводок я бы не стал (но я вообще суррогато-пурист), хотя так делают все, но гемора из-за этого ойёй, и задрали эти ограничения по балансовым группам захардкоженные в тысяче и одной мест.
...
Рейтинг: 0 / 0
13.10.2008, 17:52
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35591987
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
DaugavaПапрашу птичку, а именно структуру ProFIX/ODB не пенять. Пеняйте на свои запросы и не знание особенностей системы.

Я ее (структуру) не видел лет так 6, но судя по вашим запросам она не сильно изменилась. Из всех банковских систем, которые я видел (включая с десяток западных и десятка два украинских) - лучшая.
Я сожалею, если это лучшая АБС, с которой Вы работали. Это самая убогая и ограниченная АБС. Правда я работал всего с 5 системами.
...
Рейтинг: 0 / 0
13.10.2008, 17:58
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35592349
bk0010
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bk0010
Участник
Журавлев ДенисТ.е. запрос потенциально можно ускорить еще и еще, если сделать "правильный" индекс или правильно фрагментировать существующий индескс.
Под "фрагментировать индекс" вы имеете в виду разнести части индекса по разным дискам?
Что обычно выгоднее: собрать диски в raid 0 или фрагментировать самые затребованные таблицы?
...
Рейтинг: 0 / 0
13.10.2008, 22:38
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35592697
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Daugava
Участник
2faceЯ сожалею, если это лучшая АБС, с которой Вы работали.
Я не говорил, что это лучшая АБС это был бы уже полный оффтоп, я сказал, что у нее лучшая структура БД :). Кроме того, я не говорил, что я с ней работал, просто по роду работ приходилось конвертировать данные в/из самые различные системы.
...
Рейтинг: 0 / 0
14.10.2008, 10:14
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35593016
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
Насчет структуры БД я бы тоже поспорил. Часть таблиц "перегружены" лишними полями, некоторые очевидные связи сделаны мягко говоря странно. Индексы в таблицах, возможно, были созданы только под нужды Профикса. А т.к. набор инструментов ограничен, то возникают проблемы со скоростью выборки. До этого я работал с ораклами 9 и 10 и мссервером. Там таких проблем не было, потому что были грамотно спроектированы БД.
...
Рейтинг: 0 / 0
14.10.2008, 12:03
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35593183
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Daugava
Участник
Проектировать индексы под "другие задачи" - обязанность админа БД, а не разработчика. Да и вообще заниматься фрагментацией по условиям надо именно на конкретной инсталляции. Поскольку это все таки более менее коробочный продукт, заточенный под среднюю температуру по больнице и то, что будет хорошо Клиенту А, будет абсолютно не примлемо Клиентом Б.
Знаю я вашего "Оракла", выросшего из штанишек Интербейса, но справедливости ради его базу за вымя я не щупал, врать не буду. По "МСсерверу" - есть дельные вещи, но если бы не побег в Канаду-Штаты отцов основателей, я бы их уже задушил, как минимум за структуру ConnotationValues.
Кроме того, стоит учесть, что в отличие от приводимых вами двух основных конкурентов структура БД Профикса значительно старше и пережила изменение плана счетов в 98-году. Может я и ошибся в предположениях по конкретным разработчикам, но это врядли, поскольку узок круг широкораспространненых банковских АБС в Украине.
...
Рейтинг: 0 / 0
14.10.2008, 12:53
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35594504
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
bk0010Журавлев ДенисТ.е. запрос потенциально можно ускорить еще и еще, если сделать "правильный" индекс или правильно фрагментировать существующий индескс.
Под "фрагментировать индекс" вы имеете в виду разнести части индекса по разным дискам?
Что обычно выгоднее: собрать диски в raid 0 или фрагментировать самые затребованные таблицы?


Фрагментирование + PDQPRIORITY>=1 в 80% случаев будет быстрее.
...
Рейтинг: 0 / 0
14.10.2008, 20:42
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35594518
bk0010
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bk0010
Участник
onstatФрагментирование + PDQPRIORITY>=1 в 80% случаев будет быстрее.
Спасибо. А Mirroring тоже до сих пор актуален или лучше делать RAID 1?
...
Рейтинг: 0 / 0
14.10.2008, 21:00
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35594596
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
bk0010Под "фрагментировать индекс" вы имеете в виду разнести части индекса по разным дискам?Что обычно выгоднее: собрать диски в raid 0 или фрагментировать самые затребованные таблицы?фрагментировать -- разбить на куски. Все валим на один рейд, никаких дисков.

Создаем табличку
create table test_entry(acc char(20), adate date, sum decimal(20,2)) in speedtest;

Наполняем
execute procedure fill_te(100000);

select count(*) from test_entry;
1311763

update statistics high for table test_entry;

Мучать будем запрос
Код: plaintext
1.
2.
select {+explain} count(*)
from test_entry where adate >= '01.01.2008' and adate < '01.04.2008' and acc[ 1 , 4 ]='1111'

Создаю хороший индекс
create index ixte1 on test_entry(acc,adate) in speedtest;
Estimated Cost: 31
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
QUERY: (OPTIMIZATION TIMESTAMP: 10-14-2008 21:38:00)
------
select {+explain} count(*)

from test_entry where adate >= '01.01.2008' and adate < '01.04.2008' and acc[1,4]='1111'

DIRECTIVES FOLLOWED: 
EXPLAIN 
DIRECTIVES NOT FOLLOWED: 

Estimated Cost: 31
Estimated # of Rows Returned: 1

  1) informix.test_entry: INDEX PATH

    (1) Index Keys: acc adate   (Key-Only)  (Serial, fragments: ALL)
        Lower Index Filter: informix.test_entry.acc[1,4] = '1111' 
        Index Key Filters:  (informix.test_entry.adate >= 01/01/2008 ) AND
                            (informix.test_entry.adate < 01/04/2008 )


Query statistics:
-----------------

  Table map :
  ----------------------------
  Internal name     Table name
  ----------------------------
  t1                test_entry

  type     table  rows_prod  est_rows  rows_scan  time       est_cost
  -------------------------------------------------------------------
  scan     t1     71         90        663        00:00.01   31      

  type     rows_prod  est_rows  rows_cons  time
  -------------------------------------------------
  group    1          1         71         00:00.01


Создаем индекс фрагментированный c partition
create index ixte1 on test_entry(acc)
fragment by expression
partition p12007 adate >= '01.01.2007' and adate < '01.04.2007' in speedtest,
partition p22007 adate >= '01.04.2007' and adate < '01.07.2007' in speedtest,
partition p32007 adate >= '01.07.2007' and adate < '01.10.2007' in speedtest,
partition p42007 adate >= '01.10.2007' and adate < '01.01.2008' in speedtest,
partition p12008 adate >= '01.01.2008' and adate < '01.04.2008' in speedtest,
partition p22008 adate >= '01.04.2008' and adate < '01.07.2008' in speedtest,
partition p32008 adate >= '01.07.2008' and adate < '01.10.2008' in speedtest,
partition p42008 adate >= '01.10.2008' and adate < '01.01.2009' in speedtest;
Estimated Cost: 103
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
QUERY: (OPTIMIZATION TIMESTAMP: 10-14-2008 21:33:15)
------
select {+explain} count(*)

from test_entry where adate >= '01.01.2008' and adate < '01.04.2008' and acc[1,4]='1111'

DIRECTIVES FOLLOWED: 
EXPLAIN 
DIRECTIVES NOT FOLLOWED: 

Estimated Cost: 103
Estimated # of Rows Returned: 1

  1) informix.test_entry: INDEX PATH

        Filters: (informix.test_entry.adate >= 01/01/2008 AND informix.test_entry.adate < 01/04/2008 ) 

    (1) Index Keys: acc   (Serial, fragments: 4)
        Lower Index Filter: informix.test_entry.acc[1,4] = '1111' 


Query statistics:
-----------------

  Table map :
  ----------------------------
  Internal name     Table name
  ----------------------------
  t1                test_entry

  type     table  rows_prod  est_rows  rows_scan  time       est_cost
  -------------------------------------------------------------------
  scan     t1     71         91        71         00:00.12   104     

  type     rows_prod  est_rows  rows_cons  time
  -------------------------------------------------
  group    1          1         71         00:00.12


create index ixte1 on test_entry(acc) in speedtest;
Estimated Cost: 645
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
QUERY: (OPTIMIZATION TIMESTAMP: 10-14-2008 21:35:42)
------
select {+explain} count(*)

from test_entry where adate >= '01.01.2008' and adate < '01.04.2008' and acc[1,4]='1111'

DIRECTIVES FOLLOWED: 
EXPLAIN 
DIRECTIVES NOT FOLLOWED: 

Estimated Cost: 645
Estimated # of Rows Returned: 1

  1) informix.test_entry: INDEX PATH

        Filters: (informix.test_entry.adate >= 01/01/2008 AND informix.test_entry.adate < 01/04/2008 ) 

    (1) Index Keys: acc   (Serial, fragments: ALL)
        Lower Index Filter: informix.test_entry.acc[1,4] = '1111' 


Query statistics:
-----------------

  Table map :
  ----------------------------
  Internal name     Table name
  ----------------------------
  t1                test_entry

  type     table  rows_prod  est_rows  rows_scan  time       est_cost
  -------------------------------------------------------------------
  scan     t1     71         91        663        00:03.59   645     

  type     rows_prod  est_rows  rows_cons  time
  -------------------------------------------------
  group    1          1         71         00:03.59


без индекса
Estimated Cost: 51967
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
QUERY: (OPTIMIZATION TIMESTAMP: 10-14-2008 21:39:57)
------
select {+explain} count(*)

from test_entry where adate >= '01.01.2008' and adate < '01.04.2008' and acc[1,4]='1111'

DIRECTIVES FOLLOWED: 
EXPLAIN 
DIRECTIVES NOT FOLLOWED: 

Estimated Cost: 51967
Estimated # of Rows Returned: 1

  1) informix.test_entry: SEQUENTIAL SCAN

        Filters: ((informix.test_entry.acc[1,4] = '1111' AND informix.test_entry.adate >= 01/01/2008 ) AND informix.test_entry.adate < 01/04/2008 ) 


Query statistics:
-----------------

  Table map :
  ----------------------------
  Internal name     Table name
  ----------------------------
  t1                test_entry

  type     table  rows_prod  est_rows  rows_scan  time       est_cost
  -------------------------------------------------------------------
  scan     t1     71         90        1311763    00:02.04   51968   

  type     rows_prod  est_rows  rows_cons  time
  -------------------------------------------------
  group    1          1         71         00:02.04


хреновый индекс
create index ixte1 on test_entry(acc, sum, adate) in speedtest;
Estimated Cost: 34
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
QUERY: (OPTIMIZATION TIMESTAMP: 10-14-2008 21:42:01)
------
select {+explain} count(*)

from test_entry where adate >= '01.01.2008' and adate < '01.04.2008' and acc[1,4]='1111'

DIRECTIVES FOLLOWED: 
EXPLAIN 
DIRECTIVES NOT FOLLOWED: 

Estimated Cost: 34
Estimated # of Rows Returned: 1

  1) informix.test_entry: INDEX PATH

    (1) Index Keys: acc sum adate   (Key-Only)  (Serial, fragments: ALL)
        Lower Index Filter: informix.test_entry.acc[1,4] = '1111' 
        Index Key Filters:  (informix.test_entry.adate >= 01/01/2008 ) AND
                            (informix.test_entry.adate < 01/04/2008 )


Query statistics:
-----------------

  Table map :
  ----------------------------
  Internal name     Table name
  ----------------------------
  t1                test_entry

  type     table  rows_prod  est_rows  rows_scan  time       est_cost
  -------------------------------------------------------------------
  scan     t1     71         90        663        00:00.02   34      

  type     rows_prod  est_rows  rows_cons  time
  -------------------------------------------------
  group    1          1         71         00:00.02


наполнял так:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
CREATE PROCEDURE fill_te(a int);
    define b int; 
    for b = 1 to a
       insert into test_entry values(sp_random()||'', '10.01.2007', 0);
       insert into test_entry values(sp_random()||'', '10.04.2007', 0);
       insert into test_entry values(sp_random()||'', '10.07.2007', 0);
       insert into test_entry values(sp_random()||'', '10.10.2007', 0);
       insert into test_entry values(sp_random()||'', '10.01.2008', 0);
       insert into test_entry values(sp_random()||'', '10.04.2008', 0);
       insert into test_entry values(sp_random()||'', '10.07.2008', 0);
       insert into test_entry values(sp_random()||'', '10.10.2008', 0);       
    end for
END PROCEDURE;


CREATE PROCEDURE sp_random( ) RETURNING INTEGER; 
    DEFINE GLOBAL seed DEC( 10 ) DEFAULT 1; 
    DEFINE d DEC( 20, 0 ); 
    LET d = seed * 1103515245 + 12345; 
    LET seed = d - 4294967296 * TRUNC( d / 4294967296 ); 
    RETURN MOD( seed , 4294967296/2 ); 
END PROCEDURE;


тест получился плохой, дата одинаковая, и работает похоже все несколько иначе. Т.е. при фрагментированном индексе почему-то нет KEY-ONLY , зачем-то ходит в таблицу
...
Рейтинг: 0 / 0
14.10.2008, 22:28
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35594653
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GVF112GVF
Гость
Это батенька зря ...

Создаем индекс фрагментированный c partition
create index ixte1 on test_entry(acc)
fragment by expression
partition p12007 adate >= '01.01.2007' and adate < '01.04.2007' in speedtest,
partition p22007 adate >= '01.04.2007' and adate < '01.07.2007' in speedtest,
partition p32007 adate >= '01.07.2007' and adate < '01.10.2007' in speedtest,
partition p42007 adate >= '01.10.2007' and adate < '01.01.2008' in speedtest,
partition p12008 adate >= '01.01.2008' and adate < '01.04.2008' in speedtest,
partition p22008 adate >= '01.04.2008' and adate < '01.07.2008' in speedtest,
partition p32008 adate >= '01.07.2008' and adate < '01.10.2008' in speedtest,
partition p42008 adate >= '01.10.2008' and adate < '01.01.2009' in speedtest;

Попробуй фрагментировать индекс не для одного partition, а для нескольких db-пространств
(in speedtest1, in speedtest2, in speedtest3, in speedtest4 и т.д) !!!

С уважением,
Вадим.
...
Рейтинг: 0 / 0
14.10.2008, 23:39
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35594901
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
а теперь про умненького оракла который умеет substr



Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
SQL> set autotrace on
SQL> select count(*)
  2  from absmain.acc_Entry
  3  where  substr(EN_CNT_NUM,1,4) = '3010' and en_vir_cnt='0000.00' and en_dt_buh >= '01.01.2001' and en_dt_buh  INDEX* (FAST FULL SCAN) OF 'EN_CNT_NUM_IDX' (NON-UNIQU :Q23000E) (Cost=31 Card=4 Bytes=136)

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         226  consistent gets 
          0  physical reads
          0  redo size
        407  bytes sent via SQL*Net to client
        499  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          1  rows processed





тупим однако, переписываю в like.




Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
SQL> select count(*)
  2  from absmain.acc_Entry
  3  where  EN_CNT_NUM like '3010%' and en_vir_cnt='0000.00' and en_dt_buh >= '01.01.2001' and en_dt_buh   INDEX (RANGE SCAN) OF 'EN_CNT_NUM_IDX' (NON-UNIQUE) (Cost=4 Card=2 Bytes=68)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          13  consistent gets 
          0  physical reads
          0  redo size
        407  bytes sent via SQL*Net to client
        499  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

SQL> disc
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.8.0 - Production
...
Рейтинг: 0 / 0
15.10.2008, 09:23
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35596904
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
GVF112GVFЭто батенька зря ...
почему?

GVF112GVF
Попробуй фрагментировать индекс не для одного partition, а для нескольких db-пространств
(in speedtest1, in speedtest2, in speedtest3, in speedtest4 и т.д) !!!и зачем?
...
Рейтинг: 0 / 0
15.10.2008, 20:51
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35597023
bk0010
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bk0010
Участник
Журавлев Дениси зачем?
Возможно если заставить грузиться куски индекса с разных дисков одновременно, то это позволит улучшить те удручающие результаты, которые вы привели выше. Хотя, скорее всего, скорость выполнения увеличится только если саму таблицу разнести по дискам, но стоимость запроса при этом уменьшится вряд ли. То, что не стоит фрагментировать данные на RAIDе вы показали очень убедительно: никак не ожидал, что стоимость при этом вырастет не на проценты, а в разы.
...
Рейтинг: 0 / 0
15.10.2008, 22:13
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35597273
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
bk0010
Возможно если заставить грузиться куски индекса с разных дисков одновременно, то это позволит улучшить те удручающие результаты, которые вы привели выше. Хотя, скорее всего, скорость выполнения увеличится только если саму таблицу разнести по дискам, но стоимость запроса при этом уменьшится вряд ли. То, что не стоит фрагментировать данные на RAIDе вы показали очень убедительно: никак не ожидал, что стоимость при этом вырастет не на проценты, а в разы.бред какой-то, я показывал обратное, видимо никто не понимает что такое фрагментация и для чего ее применять. ртфм.
...
Рейтинг: 0 / 0
16.10.2008, 08:34
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35597508
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
bk0010Журавлев Дениси зачем?
Возможно если заставить грузиться куски индекса с разных дисков одновременно, то это позволит улучшить те удручающие результаты, которые вы привели выше. Хотя, скорее всего, скорость выполнения увеличится только если саму таблицу разнести по дискам, но стоимость запроса при этом уменьшится вряд ли. То, что не стоит фрагментировать данные на RAIDе вы показали очень убедительно: никак не ожидал, что стоимость при этом вырастет не на проценты, а в разы.

Денис совсем о другом хотел сказать.
Вопрос заключается в том, что если есть однозначное попадание ключа индекса
в один фрагмент, значит должен читаться только один фрагмент, а не 4.
...
Рейтинг: 0 / 0
16.10.2008, 10:26
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35597548
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Я хотел сказать что для таблицы с проводками, необходим индекс (счет,дата), но для квартальных отчетов при большом объеме таблицы (например от 500 млн записей), неплохо заиметь фрагментацию этого индекса (таблицу можно не фрагментировать, хотя при этом появляется опасность напороться на ограничения информикса).
В 2008 году -- диски шпинделя раиды роли не играют.

Еще можно заиметь таблицу счет, где балансовая группа -- отдельное индексированное поле тогда:

select dmfo, dacc, cmfo, cacc, amountuak
from vpayord, счет
where
счет.балансовая_группа in (6010,6011,6012,6013,6014,6015,6016,6017,6018)
and счет.id = vpayord.счетid
and cmfo=config_getkey('MFO','COMMON')
and dtend between MDY(3,1,2008) and MDY(3,31,2008)
...
Рейтинг: 0 / 0
16.10.2008, 10:36
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35597639
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
Журавлев ДенисЯ хотел сказать что для таблицы с проводками, необходим индекс (счет,дата), но для квартальных отчетов при большом объеме таблицы (например от 500 млн записей), неплохо заиметь фрагментацию этого индекса (таблицу можно не фрагментировать, хотя при этом появляется опасность напороться на ограничения информикса).
В 2008 году -- диски шпинделя раиды роли не играют.

Если обслуждать кулинарию приготовления отчетов, то индексов на все отчеты
ненапасешся,
Я считаю что таблицу нужно фрагментировать, а отчеты можно и фулсканом
прогнать, только следить за тем что бы база читала только один или нужный список фрагментов.

p.s. По поводу раидов и шпинделей не согласен, но спорить не буду ибо оффтопик относительно substr.
...
Рейтинг: 0 / 0
16.10.2008, 10:59
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35598858
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Daugava
Участник
Есть в этой БД таблица "Счет", и поле "балансовый счет" в этой таблице есть, вернее его id.

Кстати не помню какие там индексы на payord-е, но "config_getkey('MFO','COMMON')" жизнь не облегчает. В особенности если скрипт пишется для себя, то возможно имеет смысл указать конкретное МФО тупо в лоб, поскольку МФО имеет шансы пережить сам запрос. Хотя в общем случае это и плохо.
...
Рейтинг: 0 / 0
16.10.2008, 16:50
| Ответить | Цитировать | Написать  
51 сообщений из 51, показаны все 3 страниц
  все  
Форумы / Informix [игнор отключен] [закрыт для гостей] / Проблема с substr?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=44&tid=1607978]:
 0ms
get settings:
 8ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 71ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 82ms
get tp. blocked users:
 2ms
others: 329ms
total:  528ms
созд. / загр.: 528ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]