Убивающий IN?

Запросы, планы, оптимизация запросов, ...

Модераторы: kdv, CyberMax

stix-s
Заслуженный разработчик
Сообщения: 557
Зарегистрирован: 13 дек 2005, 11:52

Сообщение stix-s » 21 дек 2007, 14:20

kdv писал(а):C INDEX (PHONE_CALLS)
что за индекс? можешь ответить себе. мне не надо, ты и так уже умучил информацию по частям сообщать :)
это я для себя, на память :)

Код: Выделить всё

Index	  	Table	Depth Keys	Key Len	Max Dup	Total Dup	Uniques   Selectivity	Size, mb	
PHONE_CALLS	CALLS	3	1437556	2.98	6600	645964	791592	0.0000013	11.94	


kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 21 дек 2007, 15:31

не осилил ты пожелание.
какие столбцы в этот индекс входят?

stix-s
Заслуженный разработчик
Сообщения: 557
Зарегистрирован: 13 дек 2005, 11:52

Сообщение stix-s » 23 дек 2007, 17:58

kdv писал(а):не осилил ты пожелание.
какие столбцы в этот индекс входят?

Код: Выделить всё

CREATE INDEX PHONE_CALLS ON CALLS (PHONE_CALLER, PHONE_DEST);
составной, да, а что?

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 23 дек 2007, 18:12

составной, да, а что?
да ништо. с какого раза ты все это выложил, посчитай?

stix-s
Заслуженный разработчик
Сообщения: 557
Зарегистрирован: 13 дек 2005, 11:52

Сообщение stix-s » 23 дек 2007, 18:18

kdv писал(а):
составной, да, а что?
да ништо. с какого раза ты все это выложил, посчитай?
плина, вот те не спится
это так критично для запроса с использованием IN?

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 23 дек 2007, 19:41

это так критично для запроса с использованием IN?
можно я проведу сеанс? :)

Простые вещи просты, имеют простый свойства.
Из простых вещей можно сложить сложное.

когда ты спрашиваешь о сложном, подумай о том, из чего оно состоит.
Ели ты из сложного не можешь выделить простые вещи, то значит ты не понимаешь простых вещей.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 23 дек 2007, 22:08

kdv писал(а):Простые вещи просты, имеют простый свойства.
Из простых вещей можно сложить сложное.

когда ты спрашиваешь о сложном, подумай о том, из чего оно состоит.
Ели ты из сложного не можешь выделить простые вещи, то значит ты не понимаешь простых вещей.
Похоже, ты таки добрался до Хортицы :lol:

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 23 дек 2007, 23:04

нет, увы. может на следующей неделе.

я не знаю, как еще человеку объяснить, что если он привел подробности запроса только с пятого-седьмого раза, а потом еще удивляется
это так критично для запроса с использованием IN?
ну какой в жопу in, извините, когда нужно применять комплексное лечение? :)

опять же - про in написано у меня в статье. этого мало? там простой случай. ну примени ты простое над сложным примером...

stix-s
Заслуженный разработчик
Сообщения: 557
Зарегистрирован: 13 дек 2005, 11:52

Сообщение stix-s » 25 дек 2007, 13:27

kdv писал(а): я не знаю, как еще человеку объяснить, что если он привел подробности запроса только с пятого-седьмого раза, а потом еще удивляется
Дык это, как понял вопросы уточняющие, так и отвечал :(
kdv писал(а): ну какой в жопу in, извините, когда нужно применять комплексное лечение? :)
опять же - про in написано у меня в статье. этого мало? там простой случай. ну примени ты простое над сложным примером...
Я про то говорил, что не понял, имеет ли значение в данном случае индекс простой или композитный, поскольку все равно только часть использовал (по полю PHONE_CALLER), остальное в запросе не присутствует
В статье про IN читал, все там понятно, я уточнить хотел другой момент:
поскольку в запросе присутствует

Код: Выделить всё

where c.date_call>'01.11.2007'
, но индекса по этому полю нет, то:
будет навигация по индексу PHONE_CALLS - FULL SCAN, битовой карты по полю date_call не будет, и собственно условие

Код: Выделить всё

where c.date_call>'01.11.2007'
вообще, как мертвому припарка в данном случае?
Почему FB перебирает все 1,5 млн записей, когда фильтром может урезать?
Я условие это реализовал в таблице физически - удалил все записи старше '01.11.2007' (осталось где-то 230 тыс записей), запрос даже выполнился за:

Код: Выделить всё

PLAN SORT ((RX LX NATURAL) PLAN (RX LX2 NATURAL)) PLAN (C ORDER PHONE_CALLS)

------ Performance info ------
Prepare time = 0ms
Execute time = 11h 23m 28s 328ms
Avg fetch time = 2 050 416,40 ms
Current memory = 4 635 132
Max memory = 4 637 040
Memory buffers = 20 480
Reads from disk to cache = 2 462
Writes from cache to disk = 0
Fetches from cache = -887 801 070


Ответить