Z1 писал(а) 29. Октября 2007 :: 16:41:

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

kms писал(а) 29. Октября 2007 :: 17:21:

Тут вот в чем затык.
Я уже кидал сцылку http://www.sqlite.org/optoverview.html
Оптимизатор SQLite так построен, что пытается подобрать такой индекс, чтобы сделать по таблице один проход, и соответственно, пасует перед OR. Ему нужно только AND. Не спорю, что в неких частных случаях можно было бы для каждого из OR сделать по одному проходу по таблице, однако в общем случае это невозможно, так как эти несколько проходов могут "пересечся" по одним записям, и придется еще исключать дублирующиеся записи, что может перевесить выгоду от нескольких проходов по таблице.
Короче, когда SQLite передает в мой модуль ограничения по полям, то ограничения "!=" даже не передаются.

Также следует обратить внимание, что при выполнении запроса ограничения по полям, попадающим в индекс, SQLite не проверяет, так как я ему гарантирую, что они выполняются. Условия же по полям, не попавшим в индекс, он проверяет сам. При этом возможны расхождения между тем, как поля сравниваю я, и как SQLite.
Я сейчас как раз над этим эксперементирую. Возможно, сделаю так, что все условия по полям таблицы, как попадающими в индекс, так и не попадающие, буду проверять сам.

orefkov писал(а) 29. Октября 2007 :: 21:14:

Если бы ты еще коротенько объяснил, зачем тебе на текущем этапе составные "виртуальные" поля, соответствующие индексам, было бы совсем понятно.

orefkov писал(а) 29. Октября 2007 :: 21:16:

Не смеем надеяться

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

Вот кстати, кому интересно, цхмина по SQLite, содержит почти все с sqlite.org

kiruha писал(а) 30. Октября 2007 :: 10:09:

Плана запроса конечно я не вижу, но можно предположить, что в первом запросе SQLite переставил таблицы во from, и пошел по индексу date_time_iddoc в журнале, быстро подтягивая движения из регистра по id.
Во втором запросе, так как left join, то таблицы переставить нельзя, и приходится идти по всему регистру, цеплять к нему записи из журнала по id, и проверять на попадание в период.

kiruha писал(а) 30. Октября 2007 :: 11:44:

Это точно про вариант с left join?

Посмотрел план запроса.
В первом случае переставляются таблицы, делается отбор из журнала по периоду, к каждой записи цепляются движения регистра, выбираемые по id:

7      VFilter      1      85      1SJOURN.ACDATETIM;? 0;
0; // Выборка из журнала по периоду
8      VColumn      1      1       // Получение поля iddoc из журнала
9      Integer      1      0      
10      Integer      0      0      
11      VFilter      0      84      RA16602.IDLINE;?
0;  // Выборка из регистра по IDDOC


Во втором случае таблицы не переставить, выбирается ВСЕ движения из регистра, на каждое движение выбираются все записи из журнала за этот период, каждая запись из журнала сверяется с записью регистра по iddoc.

5      VFilter      0      100       // Выборка всех записей из регистра
6      MemInt      0      1      
7      String8      0      0      20060530
8      String8      0      0      20060530
9      Integer      2      0      
10      Integer      1      0      
11      VFilter      1      96      1SJOURN.ACDATETIM;? 0;
0; // Выборка записей из журнала за период