powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Informix [игнор отключен] [закрыт для гостей] / Загадочный SQL :-)
16 сообщений из 16, страница 1 из 1
Загадочный SQL :-)
    #35426539
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Потратил некоторое время, ломая голову над результатами :-)

Дано:
таблица 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 ?

В таком вот аксепте
...
Рейтинг: 0 / 0
Загадочный SQL :-)
    #35426688
olleg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
У меня так же получается, если
в t2 есть значение NULL в поле document_id.

Запрос переделал на:
Код: plaintext
1.
2.
3.
select t1.document_id from t1 
where  not exists  
( select  1  from t2 where t2.document_id= t1.document_id) 
...
Рейтинг: 0 / 0
Загадочный SQL :-)
    #35426692
olleg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
А вот еще:
Код: plaintext
1.
2.
select t1.document_id from t1 
where   0 =( select count(*) from t2 where t2.document_id= t1.document_id) 
...
Рейтинг: 0 / 0
Загадочный SQL :-)
    #35427035
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ollegА вот еще:
Код: plaintext
1.
2.
select t1.document_id from t1 
where   0 =( select count(*) from t2 where t2.document_id= t1.document_id) 



План смотрели ?
В такого рода запросах на каждое значение из t1 выполняется select из t2.

Подержу до понедельника, авось кто предложит более оптимальное решение ( с учетом того, что в t1 нет document_id = NULL)
...
Рейтинг: 0 / 0
Загадочный SQL :-)
    #35427038
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
post join predicates will help?

select t1.*
from t1 left outer join t2 on t1.documentid =t2.documentid
where t2.documentid is null
...
Рейтинг: 0 / 0
Загадочный SQL :-)
    #35429795
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Журавлев Денис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
...
Рейтинг: 0 / 0
Загадочный SQL :-)
    #35430235
olleg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
А планы моих вариантов?
В t2 были значения NULL?
Удалось найти записи из t1, отсутствующие в t2 ?
...
Рейтинг: 0 / 0
Загадочный SQL :-)
    #35430331
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Выбегалло

Ну можно и так. Только план почему-то ухудшается :-) Не говоря уж о том, что с 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 и следовательно разница в скорости.

Либо у Вас что то со статистикой, либо это какакая то фича оптимизатора которую я не понимаю.
...
Рейтинг: 0 / 0
Загадочный SQL :-)
    #35430431
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat-

Либо у Вас что то со статистикой, либо это какакая то фича оптимизатора которую я не понимаю.

Я догадываюсь в чем прикол, оптимизатор считает что прочитать
t2 через упреждающее чтение будет дешевле, чем читать индекс.

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

Остается одно предположение, таблицы маленькие, и таблица t2 состоит
из 2 (+-) полей.

Если бы таблицы были большие первый вариант и по скорости и по косту был бы быстрее.
...
Рейтинг: 0 / 0
Загадочный SQL :-)
    #35430601
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat-
Я догадываюсь в чем прикол, оптимизатор считает что прочитать
t2 через упреждающее чтение будет дешевле, чем читать индекс.
1. Индексов нет на обеих таблицах.
2. Для анси синтаксиса оптимизатор зачастую строит аригинальные планы.
3. Имхо самым лучшим в этом случае будет два seq scan и hj, но у автора возможно optcompind=0
Код: plaintext
1.
2.
select /*+use_hash(t1 /build, t2 /probe)*/ t1.*
from t1 left outer join t2 on t1.documentid =t2.documentid
where t2.documentid is null
4. Первый же ответ с where not exists , был самым труъ.
...
Рейтинг: 0 / 0
Загадочный SQL :-)
    #35430782
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Журавлев Денис onstat-
Я догадываюсь в чем прикол, оптимизатор считает что прочитать
t2 через упреждающее чтение будет дешевле, чем читать индекс.
1. Индексов нет на обеих таблицах.


Точно, недосмотрел

автор
2) informix.t2: AUTOINDEX PATH



Может стоит ему помочь построить зараннее индекс руцями, и собрать по нему статистику?
...
Рейтинг: 0 / 0
Загадочный SQL :-)
    #35430890
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat-Может стоит ему помочь построить зараннее индекс руцями, и собрать по нему статистику?Запрос надо выполнить один раз, после этого таблички дропнут.
...
Рейтинг: 0 / 0
Загадочный SQL :-)
    #35432213
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat- onstat-

Либо у Вас что то со статистикой, либо это какакая то фича оптимизатора которую я не понимаю.

Я догадываюсь в чем прикол, оптимизатор считает что прочитать
t2 через упреждающее чтение будет дешевле, чем читать индекс.

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

Остается одно предположение, таблицы маленькие, и таблица t2 состоит
из 2 (+-) полей.

Если бы таблицы были большие первый вариант и по скорости и по косту был бы быстрее.

Оптимизатор собирается строить индекс автоматически. Для построения индекса таблицу надо прочитать. А потом еще и пользоваться индексом.
При небольших таблицах ( у меня - 9к записей) проще всю таблицу втянуть в память.
...
Рейтинг: 0 / 0
Загадочный SQL :-)
    #35432223
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Журавлев Денис
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 записей каждая.
...
Рейтинг: 0 / 0
Загадочный SQL :-)
    #35434168
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Выбегалло Журавлев Денис
4. Первый же ответ с where not exists , был самым труъ.Нормальный план, он кажется страшным, но t2 сканируется не целиком. И план такой потому что optcompind 0, был бы 2, наверно было бы иначе (мне проверять лень).
...
Рейтинг: 0 / 0
Загадочный SQL :-)
    #35435407
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Журавлев Денис Выбегалло Журавлев Денис
4. Первый же ответ с where not exists , был самым труъ.Нормальный план, он кажется страшным, но t2 сканируется не целиком. И план такой потому что optcompind 0, был бы 2, наверно было бы иначе (мне проверять лень).

Остальные планы выполняются за секунду - а этот задумывается надолго.

OPTCOMPIND установлен в 1
...
Рейтинг: 0 / 0
16 сообщений из 16, страница 1 из 1
Форумы / Informix [игнор отключен] [закрыт для гостей] / Загадочный SQL :-)
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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