Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Informix [игнор отключен] [закрыт для гостей] / Загадочный SQL :-) / 16 сообщений из 16, страница 1 из 1
11.07.2008, 23:01
    #35426539
Выбегалло
Выбегалло
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Загадочный SQL :-)
Потратил некоторое время, ломая голову над результатами :-)

Дано:
таблица 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
| Ответить | Цитировать | Написать  
12.07.2008, 12:01
    #35426688
olleg
olleg
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Загадочный SQL :-)
У меня так же получается, если
в 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
| Ответить | Цитировать | Написать  
12.07.2008, 12:05
    #35426692
olleg
olleg
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Загадочный SQL :-)
А вот еще:
Код: plaintext
1.
2.
select t1.document_id from t1 
where   0 =( select count(*) from t2 where t2.document_id= t1.document_id)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.07.2008, 01:00
    #35427035
Выбегалло
Выбегалло
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Загадочный SQL :-)
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
| Ответить | Цитировать | Написать  
13.07.2008, 01:14
    #35427038
Журавлев Денис
Журавлев Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Загадочный SQL :-)
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
| Ответить | Цитировать | Написать  
14.07.2008, 22:45
    #35429795
Выбегалло
Выбегалло
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Загадочный SQL :-)
Журавлев Денис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
| Ответить | Цитировать | Написать  
15.07.2008, 09:55
    #35430235
olleg
olleg
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Загадочный SQL :-)
А планы моих вариантов?
В t2 были значения NULL?
Удалось найти записи из t1, отсутствующие в t2 ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.07.2008, 10:34
    #35430331
onstat-
onstat-
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Загадочный SQL :-)
Выбегалло

Ну можно и так. Только план почему-то ухудшается :-) Не говоря уж о том, что с 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
| Ответить | Цитировать | Написать  
15.07.2008, 11:02
    #35430431
onstat-
onstat-
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Загадочный SQL :-)
onstat-

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

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

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

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

Если бы таблицы были большие первый вариант и по скорости и по косту был бы быстрее.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.07.2008, 11:41
    #35430601
Журавлев Денис
Журавлев Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Загадочный SQL :-)
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
| Ответить | Цитировать | Написать  
15.07.2008, 12:17
    #35430782
onstat-
onstat-
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Загадочный SQL :-)
Журавлев Денис onstat-
Я догадываюсь в чем прикол, оптимизатор считает что прочитать
t2 через упреждающее чтение будет дешевле, чем читать индекс.
1. Индексов нет на обеих таблицах.


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

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



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

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

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

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

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

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

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

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

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


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