Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Загадочный SQL :-)
|
|||
|---|---|---|---|
|
#18+
Потратил некоторое время, ломая голову над результатами :-) Дано: таблица t1, полученная в результате сложного SELECTa. Таблица t2, полученная в процессе оптимизации этого самого SELECTa. Сравениваю эти таблицы - в t1 9000 записей, в t2 8000. select count(distinct document_id) from t1 возвращает все те же 9000, такой же select from t2 - 6000. Пытаюсь найти недостающие : select document_id from t1 where document_id not in ( select document_id from t2) - ничего не показывает ! :-) как переделать запрос, чтобы он таки возвращал записи из t1, отсутствующие в t2 ? В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2008, 23:01 |
|
||
|
Загадочный SQL :-)
|
|||
|---|---|---|---|
|
#18+
У меня так же получается, если в t2 есть значение NULL в поле document_id. Запрос переделал на: Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2008, 12:01 |
|
||
|
Загадочный SQL :-)
|
|||
|---|---|---|---|
|
#18+
А вот еще: Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2008, 12:05 |
|
||
|
Загадочный SQL :-)
|
|||
|---|---|---|---|
|
#18+
ollegА вот еще: Код: plaintext 1. 2. План смотрели ? В такого рода запросах на каждое значение из t1 выполняется select из t2. Подержу до понедельника, авось кто предложит более оптимальное решение ( с учетом того, что в t1 нет document_id = NULL) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2008, 01:00 |
|
||
|
Загадочный SQL :-)
|
|||
|---|---|---|---|
|
#18+
post join predicates will help? select t1.* from t1 left outer join t2 on t1.documentid =t2.documentid where t2.documentid is null ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2008, 01:14 |
|
||
|
Загадочный SQL :-)
|
|||
|---|---|---|---|
|
#18+
Журавлев Денисpost join predicates will help? select t1.* from t1 left outer join t2 on t1.documentid =t2.documentid where t2.documentid is null Ну можно и так. Только план почему-то ухудшается :-) Не говоря уж о том, что с left outer join надо постоянно помнить про порядок наложения предикатов. Query plans после update statistics high : QUERY: ------ select t1.dr_document_id from t1 left outer join t2 on (t1.dr_document_id = t2.dr_document_id) where t2.dr_document_id is null Estimated Cost: 18776 Estimated # of Rows Returned: 9136 1) informix.t1: SEQUENTIAL SCAN 2) informix.t2: AUTOINDEX PATH (1) Index Keys: dr_document_id (Key-Only) Lower Index Filter: informix.t1.dr_document_id = informix.t2.dr_document_id ON-Filters:informix.t1.dr_document_id = informix.t2.dr_document_id NESTED LOOP JOIN(LEFT OUTER JOIN) PostJoin-Filters:informix.t2.dr_document_id IS NULL Мой вариант : QUERY: ------ select t1.dr_document_id from t1 where dr_document_id not in (select dr_document_id from t2 where dr_document_id is not null) Estimated Cost: 611 Estimated # of Rows Returned: 4523 1) informix.t1: SEQUENTIAL SCAN Filters: informix.t1.dr_document_id != ALL <subquery> Subquery: --------- Estimated Cost: 303 Estimated # of Rows Returned: 8925 1) informix.t2: SEQUENTIAL SCAN Filters: informix.t2.dr_document_id IS NOT NULL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.07.2008, 22:45 |
|
||
|
Загадочный SQL :-)
|
|||
|---|---|---|---|
|
#18+
А планы моих вариантов? В t2 были значения NULL? Удалось найти записи из t1, отсутствующие в t2 ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2008, 09:55 |
|
||
|
Загадочный SQL :-)
|
|||
|---|---|---|---|
|
#18+
Выбегалло Ну можно и так. Только план почему-то ухудшается :-) Не говоря уж о том, что с left outer join надо постоянно помнить про порядок наложения предикатов. По цифрам действительно ухудшается, но обращаем внимание выделенный текст Выбегалло Query plans после update statistics high : QUERY: ------ select t1.dr_document_id from t1 left outer join t2 on (t1.dr_document_id = t2.dr_document_id) where t2.dr_document_id is null Estimated Cost: 18776 Estimated # of Rows Returned: 9136 1) informix.t1: SEQUENTIAL SCAN 2) informix.t2: AUTOINDEX PATH (1) Index Keys: dr_document_id (Key-Only) Lower Index Filter: informix.t1.dr_document_id = informix.t2.dr_document_id ON-Filters:informix.t1.dr_document_id = informix.t2.dr_document_id NESTED LOOP JOIN(LEFT OUTER JOIN) PostJoin-Filters:informix.t2.dr_document_id IS NULL Мой вариант : QUERY: ------ select t1.dr_document_id from t1 where dr_document_id not in (select dr_document_id from t2 where dr_document_id is not null) Estimated Cost: 611 Estimated # of Rows Returned: 4523 1) informix.t1: SEQUENTIAL SCAN Filters: informix.t1.dr_document_id != ALL <subquery> Subquery: --------- Estimated Cost: 303 Estimated # of Rows Returned: 8925 1) informix.t2: SEQUENTIAL SCAN Filters: informix.t2.dr_document_id IS NOT NULL То есть в первом случае читаться будет только индекс, во втором случае будет читаться таблица целяком, в зависимости от количества полей будет разница в IO и следовательно разница в скорости. Либо у Вас что то со статистикой, либо это какакая то фича оптимизатора которую я не понимаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2008, 10:34 |
|
||
|
Загадочный SQL :-)
|
|||
|---|---|---|---|
|
#18+
onstat- Либо у Вас что то со статистикой, либо это какакая то фича оптимизатора которую я не понимаю. Я догадываюсь в чем прикол, оптимизатор считает что прочитать t2 через упреждающее чтение будет дешевле, чем читать индекс. Что остается не ясным, индекс тоже можно читать упреждающим чтением и поиск по индексу дешевле с точки зрения процессора. Остается одно предположение, таблицы маленькие, и таблица t2 состоит из 2 (+-) полей. Если бы таблицы были большие первый вариант и по скорости и по косту был бы быстрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2008, 11:02 |
|
||
|
Загадочный SQL :-)
|
|||
|---|---|---|---|
|
#18+
onstat- Я догадываюсь в чем прикол, оптимизатор считает что прочитать t2 через упреждающее чтение будет дешевле, чем читать индекс. 1. Индексов нет на обеих таблицах. 2. Для анси синтаксиса оптимизатор зачастую строит аригинальные планы. 3. Имхо самым лучшим в этом случае будет два seq scan и hj, но у автора возможно optcompind=0 Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2008, 11:41 |
|
||
|
Загадочный SQL :-)
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис onstat- Я догадываюсь в чем прикол, оптимизатор считает что прочитать t2 через упреждающее чтение будет дешевле, чем читать индекс. 1. Индексов нет на обеих таблицах. Точно, недосмотрел автор 2) informix.t2: AUTOINDEX PATH Может стоит ему помочь построить зараннее индекс руцями, и собрать по нему статистику? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2008, 12:17 |
|
||
|
Загадочный SQL :-)
|
|||
|---|---|---|---|
|
#18+
onstat-Может стоит ему помочь построить зараннее индекс руцями, и собрать по нему статистику?Запрос надо выполнить один раз, после этого таблички дропнут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2008, 12:45 |
|
||
|
Загадочный SQL :-)
|
|||
|---|---|---|---|
|
#18+
onstat- onstat- Либо у Вас что то со статистикой, либо это какакая то фича оптимизатора которую я не понимаю. Я догадываюсь в чем прикол, оптимизатор считает что прочитать t2 через упреждающее чтение будет дешевле, чем читать индекс. Что остается не ясным, индекс тоже можно читать упреждающим чтением и поиск по индексу дешевле с точки зрения процессора. Остается одно предположение, таблицы маленькие, и таблица t2 состоит из 2 (+-) полей. Если бы таблицы были большие первый вариант и по скорости и по косту был бы быстрее. Оптимизатор собирается строить индекс автоматически. Для построения индекса таблицу надо прочитать. А потом еще и пользоваться индексом. При небольших таблицах ( у меня - 9к записей) проще всю таблицу втянуть в память. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2008, 20:46 |
|
||
|
Загадочный SQL :-)
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис 4. Первый же ответ с where not exists , был самым труъ. План запроса для "самого труъ ответа" :-)))) select dr_document_id from t1 where not exists ( select 1 from t2 where t2.dr_document_id= t1.dr_document_id) Estimated Cost: 7077470 Estimated # of Rows Returned: 4523 1) db_maint.t1: SEQUENTIAL SCAN Filters: NOT EXISTS <subquery> Subquery: --------- Estimated Cost: 1564 Estimated # of Rows Returned: 905 1) db_maint.t2: SEQUENTIAL SCAN Filters: db_maint.t2.dr_document_id = db_maint.t1.dr_document_id ну и выполнялся он с минуту, на друх табличках по 9000 записей каждая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2008, 20:55 |
|
||
|
Загадочный SQL :-)
|
|||
|---|---|---|---|
|
#18+
Выбегалло Журавлев Денис 4. Первый же ответ с where not exists , был самым труъ.Нормальный план, он кажется страшным, но t2 сканируется не целиком. И план такой потому что optcompind 0, был бы 2, наверно было бы иначе (мне проверять лень). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2008, 15:45 |
|
||
|
Загадочный SQL :-)
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис Выбегалло Журавлев Денис 4. Первый же ответ с where not exists , был самым труъ.Нормальный план, он кажется страшным, но t2 сканируется не целиком. И план такой потому что optcompind 0, был бы 2, наверно было бы иначе (мне проверять лень). Остальные планы выполняются за секунду - а этот задумывается надолго. OPTCOMPIND установлен в 1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2008, 03:13 |
|
||
|
|

start [/forum/search_topic.php?author=bes666&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
66ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
| others: | 822ms |
| total: | 991ms |

| 0 / 0 |
