ReSQL.ru
     
powered by simpleCommunicator - 2.0.30     © 2024 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Map
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Informix [игнор отключен] [закрыт для гостей] / Проблема поиска данных в большой таблице
22 сообщений из 47, страница 2 из 2
  2  все
Проблема поиска данных в большой таблице
    #37259622
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АнатоЛой
Участник
АнатоЛойЖуравлев Денисcliringdate должен быть в конце, для того что бы найти min(cliringdate) из индекса.
Ну тебя же не было :). А я ещё попрактивал training skill и type skill :). Или ты иеня к "как детям" в этом топике не относишь?
Ну и у ТС, надеюсь, в голове не только вывод останется - но и понимание, того почему он такой, и как к такому выводу прийти самому :)
...
Рейтинг: 0 / 0
13.05.2011, 16:37
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37259625
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
АнатоЛойЖуравлев Дениселы, как дети.
ясен пень такой запрос может выполнится за 4 наносекунды на любом компе.
только индекс нужен (portfolioid, marketplaceid, cliringdate)
cliringdate должен быть в конце, для того что бы найти min(cliringdate) из индекса.
Ну тебя же не было :). А я ещё попрактивал training skill и type skill :). Или ты иеня к "как детям" в этом топике не относишь? прости, я до тебя не дочитал :), как увидел что уже статистику и optcompind обсуждают, так и полыхнул
...
Рейтинг: 0 / 0
13.05.2011, 16:37
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37259642
dishonest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dishonest
Гость
Друзья, всем спасибо за подробные комментарии, сейчас буду дерзать, но в силу того что время уже вечернее, а на создание индексов уходит по 30 минут + потом статистику, все мои опыты и результаты скорее всего будут известны уже в понедельник ближе к вечеру. Обязательно отпишусь.
...
Рейтинг: 0 / 0
13.05.2011, 16:41
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37259647
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
dishonestДрузья, всем спасибо за подробные комментарии, сейчас буду дерзать, но в силу того что время уже вечернее, а на создание индексов уходит по 30 минут + потом статистику, все мои опыты и результаты скорее всего будут известны уже в понедельник ближе к вечеру. Обязательно отпишусь.статистику скорее всего можно не собирать, и так заработает. Индекс на такой таблице должен строится меньше 30 минут, используйте pdq .
...
Рейтинг: 0 / 0
13.05.2011, 16:42
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37259711
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Daugava
Участник
dishonest+ dbspaces не позволяет обращаться по rowid
Код: plaintext
1.
2.
3.
4.
5.
To create the rowid column, use the following SQL syntax:

    The WITH ROWIDS clause of the CREATE TABLE statement
    The ADD ROWIDS clause of the ALTER TABLE statement
    The INIT clause of the ALTER FRAGMENT statement
http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.ddi.doc/ddi100.htm
...
Рейтинг: 0 / 0
13.05.2011, 17:00
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37259879
dishonest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dishonest
Гость
Вы меня простите господа, я просто совсем не гуру так что ногами не пинайте.

АнатоЛойИтого, навскидку, без всяких проверок и тюнингов (portfolioid, marketplaceid, cliringdate).


CREATE INDEX "paveld".i_pmcd_rtorders ON "dimam".rtorders(portfolioid,marketplaceid,cliringdate);

QUERY: (OPTIMIZATION TIMESTAMP: 05-13-2011 17:07:15)
------
select
min(cliringdate), min(cliringdate) + (select d.countdate from cldocsdate d where d.cldocsid = 10002)
from rtorders
where
portfolioid = 13936
and marketplaceid in (select s.marketplaceid from printfolder s where s.cldocsid = 10002)
and cliringdate >= "01.01.2010"
and s_vstatusid = 30
and checkinid = 0
and signkind = 0;

Estimated Cost: 5
Estimated # of Rows Returned: 1

1) dimam.rtorders: INDEX PATH

Filters: ((((dimam.rtorders.checkinid = 0 AND dimam.rtorders.portfolioid = 13936 ) AND dimam.rtorders.signkind = 0 ) AND dimam.rtorders.marketplaceid = ANY <subquery> ) AND dimam.rtorders.s_vstatusid = 30 )

(1) Index Name: paveld.i_srtdc_rtorders
Index Keys: cliringdate s_rtsourceid (Aggregate) (Serial, fragments: ALL)
Lower Index Filter: dimam.rtorders.cliringdate >= 01/01/2010

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

1) paveld.s: INDEX PATH

(1) Index Name: paveld.i_cm_printfolder
Index Keys: cldocsid marketplaceid (Key-Only) (Serial, fragments: ALL)
Lower Index Filter: paveld.s.cldocsid = 1000

АнатоЛойПроверяйте скорость и план. Если в плане не тот индекс - UPD STAT MEDIUM для rtorders.

update statistics MEDIUM for table rtorders;

QUERY: (OPTIMIZATION TIMESTAMP: 05-13-2011 17:26:23)
------
select
min(cliringdate), min(cliringdate) + (select d.countdate from cldocsdate d where d.cldocsid = 10002)
from rtorders
where
portfolioid = 13936
and marketplaceid in (select s.marketplaceid from printfolder s where s.cldocsid = 10002)
and cliringdate >= "01.01.2010"
and s_vstatusid = 30
and checkinid = 0
and signkind = 0;

Estimated Cost: 5
Estimated # of Rows Returned: 1

1) dimam.rtorders: INDEX PATH

Filters: ((((dimam.rtorders.checkinid = 0 AND dimam.rtorders.portfolioid = 13936 ) AND dimam.rtorders.signkind = 0 ) AND dimam.rtorders.marketplaceid = ANY <subquery> ) AND dimam.rtorders.s_vstatusid = 30 )

(1) Index Name: paveld.i_srtdc_rtorders
Index Keys: cliringdate s_rtsourceid (Aggregate) (Serial, fragments: ALL)
Lower Index Filter: dimam.rtorders.cliringdate >= 01/01/2010

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

1) paveld.s: INDEX PATH

(1) Index Name: paveld.i_cm_printfolder
Index Keys: cldocsid marketplaceid (Key-Only) (Serial, fragments: ALL)
Lower Index Filter: paveld.s.cldocsid = 10002

АнатоЛойЕсли и после этого не тот индекс в плане - возможно вместо marketplaceid IN(...) стоит преобразовать запрос в простое соединение rtorders с cldocsdate).


Да вообще выкинул ради пробы
Пошел в новый index, результат абсолютно точно такой же с которого начинался пост, но печальночто нет связи с площадками

QUERY: (OPTIMIZATION TIMESTAMP: 05-13-2011 17:30:06)
------
select
min(cliringdate), min(cliringdate) + (select d.countdate from cldocsdate d where d.cldocsid = 10002)
from rtorders
where
portfolioid = 13936
and marketplaceid = 26 --in (select s.marketplaceid from printfolder s where s.cldocsid = 10002)
and cliringdate >= "01.01.2010"
and s_vstatusid = 30
and checkinid = 0
and signkind = 0;

Estimated Cost: 3
Estimated # of Rows Returned: 1

1) dimam.rtorders: INDEX PATH

Filters: ((dimam.rtorders.checkinid = 0 AND dimam.rtorders.signkind = 0 ) AND dimam.rtorders.s_vstatusid = 30 )

(1) Index Name: paveld.i_pmcd_rtorders
Index Keys: portfolioid marketplaceid cliringdate (Aggregate) (Serial, fragments: ALL)
Lower Index Filter: ((dimam.rtorders.marketplaceid = 26 AND dimam.rtorders.portfolioid = 13936 ) AND dimam.rtorders.cliringdate >= 01/01/2010 )

Попробывал след запрос, виден в плане, скорость даже смотреть не буду, стоимости уже хватило.. чота дето у меня в косерватории
QUERY: (OPTIMIZATION TIMESTAMP: 05-13-2011 17:41:00)
------
select
min(cliringdate), min(cliringdate) + (select d.countdate from cldocsdate d where d.cldocsid = 10002)
from rtorders, printfolder
where
portfolioid = 13936
and rtorders.marketplaceid = printfolder.marketplaceid
and printfolder.cldocsid = 10002
and cliringdate >= "01.01.2010"
and s_vstatusid = 30
and checkinid = 0
and signkind = 0;

Estimated Cost: 2723151
Estimated # of Rows Returned: 1

1) paveld.printfolder: INDEX PATH

(1) Index Name: paveld.i_cm_printfolder
Index Keys: cldocsid marketplaceid (Key-Only) (Serial, fragments: ALL)
Lower Index Filter: paveld.printfolder.cldocsid = 10002

2) dimam.rtorders: INDEX PATH

Filters: (((dimam.rtorders.checkinid = 0 AND dimam.rtorders.signkind = 0 ) AND dimam.rtorders.s_vstatusid = 30 ) AND dimam.rtorders.cliringdate >= 01/01/2010 )

(1) Index Name: informix.tmp_idx
Index Keys: marketplaceid portfolioid (Serial, fragments: ALL)
Lower Index Filter: (dimam.rtorders.marketplaceid = paveld.printfolder.marketplaceid AND dimam.rtorders.portfolioid = 13936 )
NESTED LOOP JOIN

Сейчас все таки попробую еще раз трезво на все взглянуть.
...
Рейтинг: 0 / 0
13.05.2011, 18:07
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37260227
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
dishonest,

вместо того чтобы смотреть стоимость, смотрите время выполнения. А лучше всего, если сервер в вашем полном распоряжении, смотрите число disk reads (onstat -p)

Я, когда тестирую запрос, делаю так:

onmode -ky;oninit -v;wait 10;onstat -z; time dbaccess <имя базы> <мой скрипт>.sql; wait 10; onstat -p

То есть - положить сервер, поднять, подождать 10 сек, сбросить статистику, замерить время выполнения скрипта, подождать 10 сек, получить статистику
Чем меньше disk reads тем лучше, их надо сравнивать с предыдущей версией скрипта, изменение времени выполнения скрипта прямо пропорционально изменению дисковых чтений
...
Рейтинг: 0 / 0
13.05.2011, 22:06
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37260236
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
dishonest
АнатоЛойПроверяйте скорость и план. Если в плане не тот индекс - UPD STAT MEDIUM для rtorders.

update statistics MEDIUM for table rtorders;



Попробуйте UPDATE HIGH для portfolioid,marketplaceid,cliringdate.
Возможно, у вас не обновилось distribution

dishonestАнатоЛойЕсли и после этого не тот индекс в плане - возможно вместо marketplaceid IN(...) стоит преобразовать запрос в простое соединение rtorders с cldocsdate).


Да вообще выкинул ради пробы
Пошел в новый index, результат абсолютно точно такой же с которого начинался пост, но печальночто нет связи с площадками

QUERY: (OPTIMIZATION TIMESTAMP: 05-13-2011 17:30:06)
------
select
min(cliringdate), min(cliringdate) + (select d.countdate from cldocsdate d where d.cldocsid = 10002)
from rtorders
where
portfolioid = 13936
and marketplaceid = 26 --in (select s.marketplaceid from printfolder s where s.cldocsid = 10002)
and cliringdate >= "01.01.2010"
and s_vstatusid = 30
and checkinid = 0
and signkind = 0;



перепишите как

select
min(cliringdate), min(cliringdate) + (select d.countdate from cldocsdate d where d.cldocsid = 10002)
from rtorders
where
portfolioid = 13936
and marketplaceid in (select s.marketplaceid from printfolder s where s.cldocsid = 10002 and s.marketplaceid = rtorders.marketplaceid )
and cliringdate >= "01.01.2010"
and s_vstatusid = 30
and checkinid = 0
and signkind = 0;
...
Рейтинг: 0 / 0
13.05.2011, 22:13
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37260307
alexey_mas1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexey_mas1
Гость
также
Код: plaintext
1.
and marketplaceid in (select s.marketplaceid from printfolder s where s.cldocsid =  10002 )

заменить на
Код: plaintext
 and exists (select  1  from printfolder s where s.cldocsid= 10002  and s.marketplace=rtorders.marketplace)
...
Рейтинг: 0 / 0
14.05.2011, 00:06
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37260416
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Журавлев Дениселы, как дети.

ясен пень такой запрос может выполнится за 4 наносекунды на любом компе.

только индекс нужен (portfolioid, marketplaceid, cliringdate)

cliringdate должен быть в конце, для того что бы найти min(cliringdate) из индекса.


перечитал исходную портянку целиком, оказывается там есть еще селективный предикат

and checkinid = 0 and signkind = 0;

поэтому дата тут вообще возможно не нужна

я не понял как идентифицируется клиент, парой portfolioid, marketplaceid или бывают запросы только отдельно portfolioid, поэтому индекс должен быть или

portfolioid, checkinid, signkind, marketplaceid
или
portfolioid, marketplaceid, checkinid, signkind
для конкретно этого запроса разницы конечно нет.

Если записей portfolioid=, marketplaceid=, checkinid=0, signkind=0 больше ста то тогда я бы у себя сделал индекс
portfolioid, marketplaceid, checkinid, signkind, cliringdate


И я бы соединил checkinid, signkind в один аттрибут status
...
Рейтинг: 0 / 0
14.05.2011, 09:33
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37260573
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АнатоЛой
Участник
dishonestПопробывал след запрос, виден в плане, скорость даже смотреть не буду, стоимости уже хватило.. чота дето у меня в косерватории
QUERY: (OPTIMIZATION TIMESTAMP: 05-13-2011 17:41:00)
------
select
min(cliringdate), min(cliringdate) + (select d.countdate from cldocsdate d where d.cldocsid = 10002)
from rtorders, printfolder
where
portfolioid = 13936
and rtorders.marketplaceid = printfolder.marketplaceid
and printfolder.cldocsid = 10002
and cliringdate >= "01.01.2010"
and s_vstatusid = 30
and checkinid = 0
and signkind = 0;

Estimated Cost: 2723151
Estimated # of Rows Returned: 1

1) paveld.printfolder: INDEX PATH

(1) Index Name: paveld.i_cm_printfolder
Index Keys: cldocsid marketplaceid (Key-Only) (Serial, fragments: ALL)
Lower Index Filter: paveld.printfolder.cldocsid = 10002

2) dimam.rtorders: INDEX PATH

Filters: (((dimam.rtorders.checkinid = 0 AND dimam.rtorders.signkind = 0 ) AND dimam.rtorders.s_vstatusid = 30 ) AND dimam.rtorders.cliringdate >= 01/01/2010 )

(1) Index Name: informix.tmp_idx
Index Keys: marketplaceid portfolioid (Serial, fragments: ALL)
Lower Index Filter: (dimam.rtorders.marketplaceid = paveld.printfolder.marketplaceid AND dimam.rtorders.portfolioid = 13936 )
NESTED LOOP JOIN



Стоимость выполнения запроса измеряеится в попугаях, причём это ОЦЕНОЧНАЯ стоимость, типа прогноза погоды :).
1) +1 к предыдущим - и время таки проверить стоит, и дисковые операциию.
2) таки реально попробуйте простой запрос - с обращением только к одной таблице и константами. Если он Вас устроит по скорости - только тогда постепенно добавляйте новые условия и проверяйие план запроса и реальное поведение сервера (время, чтения дисков).
При отклонениях от ожидаемого поведения - много думайте, пишите сюда :)
...
Рейтинг: 0 / 0
14.05.2011, 13:16
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37262269
dishonest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dishonest
Гость
Друзья, в общем и так и этак попробовал. Остановился на следующем варианте.
Создал себе индекс
CREATE INDEX "paveld".i_pchmd_rtorders ON "dimam".rtorders(portfolioid,checkinid,marketplaceid,cliringdate);

Далее план двух нужных мне запросов

QUERY: (OPTIMIZATION TIMESTAMP: 05-16-2011 11:18:58)
------
select
min(cliringdate), min(cliringdate) + (select d.countdate from cldocsdate d where d.cldocsid = 10002)
from rtorders
where
portfolioid = 13936
and checkinid = 0
and marketplaceid = 26 -- in (select s.marketplaceid from printfolder s where s.cldocsid = 10002)
and cliringdate >= "01.01.2010"
and s_vstatusid = 30
and signkind = 0;

Estimated Cost: 3
Estimated # of Rows Returned: 1

1) dimam.rtorders: INDEX PATH

Filters: (dimam.rtorders.signkind = 0 AND dimam.rtorders.s_vstatusid = 30 )

(1) Index Name: paveld.i_pchmd_rtorders
Index Keys: portfolioid checkinid marketplaceid cliringdate (Aggregate) (Serial, fragments: ALL)
Lower Index Filter: (((dimam.rtorders.checkinid = 0 AND dimam.rtorders.marketplaceid = 26 ) AND dimam.rtorders.portfolioid = 13936 ) AND dimam.rtorders.cliringdate >= 01/01/2010 )


QUERY: (OPTIMIZATION TIMESTAMP: 05-16-2011 11:19:16)
------
SELECT
count(*)
FROM rtorders rt
WHERE
rt.portfolioid = 13936
and rt.checkinid = 0 --не принадлежат документу
and rt.marketplaceid in (select s.marketplaceid from printfolder s where s.cldocsid = 10002)
and rt.cliringdate >= "04.05.2010"
and rt.cliringdate <= date('04.05.2010')+10
and rt.s_vstatusid = 30 --готовы к обработке
and rt.signkind = 0 --признак ЭЦП подписи Квика

Estimated Cost: 20314
Estimated # of Rows Returned: 1

1) paveld.rt: INDEX PATH

Filters: (paveld.rt.signkind = 0 AND paveld.rt.s_vstatusid = 30 )

(1) Index Name: paveld.i_pchmd_rtorders
Index Keys: portfolioid checkinid marketplaceid cliringdate (Serial, fragments: ALL)
Lower Index Filter: (((paveld.rt.checkinid = 0 AND paveld.rt.portfolioid = 13936 ) AND paveld.rt.cliringdate >= 04/05/2010 ) AND paveld.rt.marketplaceid = ANY <subquery> )
Upper Index Filter: paveld.rt.cliringdate <= 14/05/2010

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

1) paveld.s: INDEX PATH

(1) Index Name: paveld.i_cm_printfolder
Index Keys: cldocsid marketplaceid (Key-Only) (Serial, fragments: ALL)
Lower Index Filter: paveld.s.cldocsid = 10002


В первом запросе выкинул конструкцию выборки площадок для печатаемого документа. Если использовать in или or или exists (константами либо селект), либо еще как либо пытаться их туда перечислить то первое на что мы натыкаемся это выборка все потому же индексу который я указал в самом начале поста. Далее все те же 20 и более секунд.
В общем я решил что раз уж эта беда зашита у меня в хранимой процедуре, использовать курсор для выборки площадок для документа, по нему выполнять запрос на получение минимальной даты. Ибо запросы в таком виде и под ваши комментарии с индексами на текущий момент работают действительно 4 наносекунды. Всем спасибо буду двигаться дальше.
...
Рейтинг: 0 / 0
16.05.2011, 11:34
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37262400
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
dishonestДалее все те же 20 и более секунд.
работают действительно 4 наносекунды.
...
Рейтинг: 0 / 0
16.05.2011, 12:26
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37263371
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
старшие товарищи говорят я неправильную картинку положил. Попробую еще раз:
...
Рейтинг: 0 / 0
16.05.2011, 19:00
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37264561
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АнатоЛой
Участник
Журавлев ДенисdishonestДалее все те же 20 и более секунд.
работают действительно 4 наносекунды.
Я ничего не понял!

Чё непонятно-то?
Если в запросе для marketplaceid написано " = 26" - всё летает в 4 наносекунды (и использует "правильный" индекс)
Если в запросе для marketplaceid задачу усложнить (
1) marketplaceid in (select ..);
2) marketplaceid= x or marketplaceid = y;
3) exists (select from a where a.x = rtorders))

всё возвращается к исходному "плохому" индексу... Поскольку у ТС есть возможность поменять запрос, ТС не стал париться - и поменял его :)

ТС, ради интереса, попробуй просто JOIN! :


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
select
   min(o.cliringdate), min(o.cliringdate) + (select d.countdate from cldocsdate d where d.cldocsid =  10002 )
  from printfolder s, rtorders o
    where
        s.cldocsid =  10002 
        and o.portfolioid =  13936 
        and o.checkinid =  0 
        and o.marketplaceid = s.marketplaceid 
        and o.cliringdate >= "01.01.2010"
        and o.s_vstatusid =  30 
        and o.signkind =  0 ;
...
Рейтинг: 0 / 0
17.05.2011, 13:21
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37264783
dishonest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dishonest
Гость
АнатоЛойЖуравлев Дениспропущено...

Я ничего не понял!

Чё непонятно-то?
Если в запросе для marketplaceid написано " = 26" - всё летает в 4 наносекунды (и использует "правильный" индекс)
Если в запросе для marketplaceid задачу усложнить (
1) marketplaceid in (select ..);
2) marketplaceid= x or marketplaceid = y;
3) exists (select from a where a.x = rtorders))

всё возвращается к исходному "плохому" индексу... Поскольку у ТС есть возможность поменять запрос, ТС не стал париться - и поменял его :)

ТС, ради интереса, попробуй просто JOIN! :


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
select
   min(o.cliringdate), min(o.cliringdate) + (select d.countdate from cldocsdate d where d.cldocsid =  10002 )
  from printfolder s, rtorders o
    where
        s.cldocsid =  10002 
        and o.portfolioid =  13936 
        and o.checkinid =  0 
        and o.marketplaceid = s.marketplaceid 
        and o.cliringdate >= "01.01.2010"
        and o.s_vstatusid =  30 
        and o.signkind =  0 ;


Я уже выше же приводил пример с планом такого запроса.. указывал на стоимость(попугаи) да и скорость была удручающей...
...
Рейтинг: 0 / 0
17.05.2011, 14:53
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37264799
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
а с хинтом +index план вашего запроса покажите?

а план вот такого запроса:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
select --+explain 
min(cliringdate)
from 
(select --+explain first_rows index (r,i_pchmd_rtorders)
 cliringdate,  (select distinct  1  from printfolder s where s.cldocsid =  10002  and s.marketplaceid=r.marketplaceid)  c
from rtorders r 
where
cliringdate >= '01.01.2010'
and portfolioid =  13936 
and s_vstatusid =  30 
and checkinid =  0 
and signkind =  0 
order by portfolioid, checkinid, marketplaceid, cliringdate)
where  c =  1
...
Рейтинг: 0 / 0
17.05.2011, 14:58
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37265453
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АнатоЛой
Участник
Журавлев Дениса с хинтом +index план вашего запроса покажите?

а план вот такого запроса:
...skipped...

с ума сойти можно...
Денис, это попытка разобраться в путях Господних оптимизатора, или реальное предложение к использованию в продуктиве?
...
Рейтинг: 0 / 0
17.05.2011, 17:50
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37265492
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
АнатоЛойЖуравлев Дениса с хинтом +index план вашего запроса покажите?

а план вот такого запроса:
...skipped...

с ума сойти можно...
Денис, это попытка разобраться в путях Господних оптимизатора, или реальное предложение к использованию в продуктиве?Просто интересно какой план будет. Ничего примечательного в запросе нет, в оракле у меня такой каждый второй.

Т.е.
select *
from t
where t.d = select max(t.d) from t

удобно заменять на:
select first 1 *
from t
order by t.d desc
...
Рейтинг: 0 / 0
17.05.2011, 18:00
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37265549
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АнатоЛой
Участник
Журавлев ДенисПросто интересно какой план будет. Ничего примечательного в запросе нет, в оракле у меня такой каждый второй.
Или я под конец дня туплю, или твой запрос не идентичен тому, что требуется ТС: в твоём запросе нет нужных ограничений по marketplaceid...
Разве что тебе интересен план запроса БЕЗ требования получить результат, который нужен ТСу..
...
Рейтинг: 0 / 0
17.05.2011, 18:18
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37265677
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
АнатоЛойЖуравлев ДенисПросто интересно какой план будет. Ничего примечательного в запросе нет, в оракле у меня такой каждый второй.
Или я под конец дня туплю, или твой запрос не идентичен тому, что требуется ТС: в твоём запросе нет нужных ограничений по marketplaceid...
Разве что тебе интересен план запроса БЕЗ требования получить результат, который нужен ТСу..он не идентичен, в том плане что я заменил in на "exists", там в секции селект коррелированным запросом выбирается 1 если на этой площадке торговали, а во внешнем запросе ограничивается c = 1.
...
Рейтинг: 0 / 0
17.05.2011, 19:10
| Ответить | Цитировать | Написать  
Проблема поиска данных в большой таблице
    #37268211
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АнатоЛой
Участник
Журавлев ДенисАнатоЛойпропущено...

Или я под конец дня туплю, или твой запрос не идентичен тому, что требуется ТС: в твоём запросе нет нужных ограничений по marketplaceid...
Разве что тебе интересен план запроса БЕЗ требования получить результат, который нужен ТСу..он не идентичен, в том плане что я заменил in на "exists", там в секции селект коррелированным запросом выбирается 1 если на этой площадке торговали, а во внешнем запросе ограничивается c = 1.
ммм... только теперь проняло.

П.С.: DBMS это наше BDSM :)
...
Рейтинг: 0 / 0
18.05.2011, 20:37
| Ответить | Цитировать | Написать  
22 сообщений из 47, страница 2 из 2
  2  все
Форумы / Informix [игнор отключен] [закрыт для гостей] / Проблема поиска данных в большой таблице
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru, Чат Кролика       Пашэ: Рисунки, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=44&msg=37264561&tid=1607353]:
 0ms
get settings:
 7ms
get forum list:
 5ms
check forum access:
 1ms
check topic access:
 1ms
track hit:
 30ms
get topic data:
 3ms
get forum data:
 1ms
get page messages:
 383ms
get tp. blocked users:
 0ms
others: 7ms
total:  438ms
созд. / загр.: 438ms
x
x
Закрыть


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