Простенький вопросик для знатоков от зрителей :)
Почему настоятельно не рекомендуется использовать оператор ИЛИ в условии запроса?

(61) Сходил на семинар и все можно?
Что этот 1Снег себе позволяет?

(62) для тех кто не ходил на семинар, а что там у нас с кешированием в (57)?

Запрос с простым И

"result  (cost=0.00..4.08 rows=1 width=19) (actual time=0.000..0.000 rows=0 loops=1)
  one-time filter: false
  ->  index only scan using _docum10341_bydocnum_sr on Документ.XXXXXXXXXX t1  (cost=0.00..4.08 rows=1 width=19) (never executed)
        index cond: (Номер = '000000011'::mvarchar)
        heap fetches: 0
total runtime: 0.018 ms
"

"limit  (cost=0.00..4.09 rows=1 width=0) (actual time=0.023..0.023 rows=0 loops=1)
  ->  index scan using pg_class_relname_nsp_index on pg_class  (cost=0.00..4.09 rows=1 width=0) (actual time=0.022..0.022 rows=0 loops=1)
        index cond: (relname = 'tt82'::name)
        filter: (pg_table_is_visible(oid) and (relkind = 'r'::""char""))
total runtime: 0.040 ms
"

Вместо И установил ИЛИ


"bitmap heap scan on Документ.XXXXXXXXXX t1  (cost=4.15..8.11 rows=2 width=19) (actual time=1.536..1.539 rows=2 loops=1)
  recheck cond: ((Номер = '000000011'::mvarchar) or (Номер = '000000010'::mvarchar))
  ->  bitmapor  (cost=4.15..4.15 rows=2 width=0) (actual time=1.530..1.530 rows=0 loops=1)
        ->  bitmap index scan on _docum10341_bydocnum_sr  (cost=0.00..2.07 rows=1 width=0) (actual time=1.517..1.517 rows=1 loops=1)
              index cond: (Номер = '000000011'::mvarchar)
        ->  bitmap index scan on _docum10341_bydocnum_sr  (cost=0.00..2.07 rows=1 width=0) (actual time=0.012..0.012 rows=1 loops=1)
              index cond: (Номер = '000000010'::mvarchar)
total runtime: 1.560 ms
"

"limit  (cost=2.10..9.61 rows=1 width=0) (actual time=0.037..0.037 rows=0 loops=1)
  ->  bitmap heap scan on pg_class  (cost=2.10..9.61 rows=1 width=0) (actual time=0.036..0.036 rows=0 loops=1)
        recheck cond: (relname = 'tt35'::name)
        filter: (pg_table_is_visible(oid) and (relkind = 'r'::""char""))
        rows removed by filter: 2
        ->  bitmap index scan on pg_class_relname_nsp_index  (cost=0.00..2.10 rows=4 width=0) (actual time=0.010..0.010 rows=7 loops=1)
              index cond: (relname = 'tt35'::name)
total runtime: 0.054 ms
"

(64) Еретический план запроса.
Тебя надо предать анафеме.

А вот объединить все

"result  (cost=0.00..8.15 rows=2 width=19) (actual time=0.040..0.051 rows=2 loops=1)
  ->  append  (cost=0.00..8.15 rows=2 width=19) (actual time=0.040..0.051 rows=2 loops=1)
        ->  index only scan using _docum10341_bydocnum_sr on Документ.ХХХХХХХХХХ t1  (cost=0.00..4.08 rows=1 width=19) (actual time=0.039..0.039 rows=1 loops=1)
              index cond: (Номер = '000000011'::mvarchar)
              heap fetches: 1
        ->  index only scan using _docum10341_bydocnum_sr on Документ.ХХХХХХХХХХ t2  (cost=0.00..4.08 rows=1 width=19) (actual time=0.010..0.010 rows=1 loops=1)
              index cond: (Номер = '000000010'::mvarchar)
              heap fetches: 1
total runtime: 0.079 ms
"

(66) Не сложно заметить, что второй запрос работает чутка лучше )))

(65) у меня еще пачка логинов в запасе ))) пффффф

(66) Я правильно вижу indexscan в нем?

Index Scan — используется индекс для условий WHERE, читает таблицу при отборе строк.
Bitmap Index Scan — сначала Index Scan, затем контроль выборки по таблице. Эффективно для большого количества строк.

как я понимаю, в постгре чуть по другому идет работа с индексами

(70)
Index Only Scan выполняется быстрее, чем Index Scan за счёт того, что не требуется читать строку таблицы полностью

(70) (71) В сортах мммм. Постгрии не разбираюсь :-)

(72) Ну зря ты так, из бесплатных СУБД, пожалуй, лучшая. То, что 1С её мучает - это проблема заточенности 1С под MS SQL Server(уже говорили в этой ветке).

Так выглядит не попадание в индекс, то есть дырка в индексах:

"aggregate  (cost=4.08..4.08 rows=1 width=19) (actual time=0.035..0.035 rows=1 loops=1)
  ->  index scan using _docum10341_bydocnum_sr on Документ.ХХХХХХХХХХ t1  (cost=0.00..4.08 rows=1 width=19) (actual time=0.022..0.025 rows=1 loops=1)
        index cond: (Номер = '000082891'::mvarchar)
        filter: (СтруктурнаяЕдиница = '\\x5d9a0007e932f60411e163a8025e9964'::bytea)
total runtime: 0.073 ms
"

то есть надо обращать внимание на постгре что бы было слово index cond и не было filter...

в майстайном сервере это seek ..... where

(72) Пока тоже не разбираюсь, но вот пришлось сталкнуться... даже пришлось собиратель плана запроса от 1С доработать, так как вся линейка продуктов 1С заточена на Win... А с линуксом отказывается работать

(73) Вполне добротно работает.... если бы не подножки , которые 1С подстроила, а именно отсутствие инструментария если субд расположена на линуксах

(76) Ну кабы не работало - никто бы не пользовался )

(9) Да чепуха все это, к этим советам надо всегда относиться с известной долей скептицизма и проверять на реальных данных. Те советы писались в махровые 2000 годы такими же "спецами" как вы сами.

(47) Что нет?

(52) Приведи годный пример/

(80) см. (41) (42)

У меня пару раз возникал следующий вопрос..
Что будет со временем выполнения запроса, если условие с ИЛИ заменить на условие с И?

ГДЕ А ИЛИ Б
->
ГДЕ НЕ ((НЕ А) И (НЕ Б))

Есть знатоки?

(82) тоже самое

(83) Из-за оптимизатора запроса, который заменит ИЛИ на И?

Битва гигантов, если честно очень познавательно. А вопрос (82) вообще +100500

(44) Только иногда этой причиной является timeout.

(44) В мире нет ничего ВНЕЗАПНОГО. Даже генератор случайных чисел генерирует не случайные числа и вообще вселенная детермеринована.
Однако, когда postgresql выбирает план, выполняющий запрос 30 минут,тогда как 5 лет до этого стабильно выбирал план, выполняющий запрос за 3 секунды - это почему-то оказывается ВНЕЗАПНО

(82) условие НЕ В (&Массив)

Чтобы не париться с планом запроса по условию ИЛИ, можно выбрать данные в временную таблицу, проиндексировать нужные поля, а потом фильтрануть ее.

(84) Ну представь себе телефонный справочник, представь, что надо выбрать всех не Ивановых и не Сергеев. Придется перебирать весь справочник фактически. Исключением будут являтся разве что логические типы, где НЕ вернет конкретное значение, которое можно сравнить на эквивалентность и использовать индекс по нему.

(89) Чтобы не париться с поиском организаций, у которых ИНН заканчивается на 351, я предлагаю переписать из справочника к себе в тетрадочку только те организации, у которых ИНН заканчивается на  351!!!

Еще можно обойти ИЛИ с помощью CASE When Then.
Скульщики говорят, что утверждение, что Case работает не используя индексы - лживое.

(92) Утверждение, что ИЛИ не использует индексы - тоже лживое.

(93) глубоко не знаю, но думаю, что построение плана запроса зависит от очень многих факторов. Начиная от собственной статистики скуля по обращению к таблицам и заканчивая их объемами, индексами и прочим.

(91) Прекрасно!

совет (89) прекрасно иллюстрирует всю сущщность "специалистов".

Сегодня с таблицей мало работают - план запроса один, завтра куча народу строит отчеты по таблице - план запроса другой.

(97) Бред.

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

(96) (98) не буду спорить. Оставайся при своем мнении.

(94) План запроса зависит от незначительного числа факторов.

(101) Но эти незначительные факторы могут выливаться в сложные системы, в которых черт ногу сломит и сам оптимизатор забивает, потому что не успевает ниче придумать, и отдаёт всякую хрень.

(101) это многое объясняет

(99) Ты счаст ему ничего не сказал.
Надо показать табличку статистики и сказать, что для значения из этого диапазона будет выбрано примерно столько то X записей из всего объема Y.

Ну и показать запросы по полной выборке из всех таблиц при
Update statistics with fullscan

(104) Согласен, однако задачи обучить кого-то не стоит.

(90) >Придется перебирать весь справочник фактически
Т.е. про индексы при таком раскладе можно забыть?

(106) Если поле логического типа - нет. В остальных случаях - да. Умение быстро найти в куче нужный тебе элемент ничерта не помогает, когда тебе как раз он то и не нужен.
< или > позволяет гарантированно определить диапазоны с ненужными данными и отсечь их.
а <>....

(107) Ну и еще оговорюсь - все эти мои пассажи относятся не к НЕ, а к имено к <>, который зачастую там получается  в итоге

(106) раз тебе ивановых часто искать надо и их номера, то может механизм полнотекстового поиска тебе поможет в этом?

(109) Будь внимательнее - речь шла про подмену ИЛИ из конструкций НЕ и И

я бы предложил товарищу в (0) почитать соответствующую литературу, но как, и многие тут, не хочу плодить дешевых и бестолковых конкурентов.

(111) Тот которые пытается что то познать дешевым и бестолковым не будет.

(110) Без ИЛИ всегда можно обойтись, как и без Полного Внешнего Соединения. Есть масса вариантов и они уже описаны выше.
По своему опыту использую эти вещи крайне редко.

(113) Правильно , ИЛИ можно заменить на объединить все.

(112) очень много ложных знаний и пафосных советчиков, владеющих ими, которые и не знания вовсе.
Хочешь что-то познать - надо читать авторитетную литературу.

(115) Советчиков тоже надо слушать, они подталкиваю в верное направление. Ну и конечно книги и конечно самим потрогать...

:)

(109) Механизм полнотекстового поиска - этот ровно тот же механизм индексов, который строит индексы для всех подстрок строки.

Тоесть, есть у нас строка
"Индианаполис"
обычный индексный поиск построит для нее индекс для значения
"Индианаполиc"

Этот индекс будет использоваться для условия вида
ПОДОБНО "Индиана%"
но не для условий
ПОДОБНО "%полис"

Полнотекстовый индекс построит 100500 индексов, в т.ч. для слова
"полис"

и в случае поиска по условию
ПОДОБНО "%полис"
будет использован.

Но для обновления данных индексов нужно 100500 времени, поэтому это нечастый процесс.

(118) чем я тебя зацепил то?

(118) есть два индекса в механизме : основной - он долго строится и дополнительный.
Основной самый быстрый, формируется периодически регламентным заданием , а дополнительный - это медленный индекс, в него попадает оперативная информация.
Поиск осуществляется сначала в основном, потом в дополнительном.
Так называемое обновление данных - это слияние индексов с целью освобождения дополнительного.


http://www.vnedriupp.ru/index.php?content=8301

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

(115) Если бы ты сам читал - не писал бы всякого бреда.

(122) закусывай

(122) я, мля одинесом 14 лет занимаюсь. И добуя советчиков читал, которые сидят тут чтобы повыпендриваться

(124) Это печально.

(120) Это прекрасная статья. Которая не рассказывает про физику процесса. Физика остается черным ящиком.

(125) уже говорили как-то, что красота кода - это для убеленных сединами старцев. Которые не имеют вала задач и имеют много времени для медитаций.

(119) Ничем.
Ты просто забавный со своим ООП, null и, как оказалось, невежеством.

(127) Годный кот пишут фикси. Ибо они планируют с ним же работать. Кот "наотщепись" пишут фри-фра. Ибо "траванерасти".
Все просто.

(127) Это печально - это к 14 годам.
К 14 годам занятий 1С-ом нужно разбираться во ВСЕМ.

До недавнего времени я тоже щитал, что хорошо знаю 1С и инф. системы и они просты как молоток. Как оказалось - 1С - дочерта сложная штука и требует от прогера дозвизды знаний. Просто 95% прогеров об этом не знают.

(129) завидую тебе, есть время на медитации и вникание в физику процессов...

(132) Лучше день потерять, потом за 5 минут долететь.

(133) ответь мне на вопрос один.
Ты сидишь наверно начальником, ковыряешься в носу и имеешь массу свободного Времени чтобы сидеть на мисте и с высоты своего положения троллить обычных работяг?

(134) Ну, юридически я простой программист.
В мисту погружен, но не критично.
Время есть, потому что:
1) Быстро и без ошибок пишу в своих конфах.
2) Часто работаю дома, по ночам, над несложными/интересными задачами.

(134) Троллить невежественных 1Сников считаю за долг, невежественные 1Сники бросают тень на блистательный образ автоматизаторов Отечества.

(136) Брось, у тебя мания величия :) Троллить и без тебя есть кому.

(133) +1

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

(137) Не мешай троллить :-)

(135) работаю на такой работе, где 60% процентов задач надо по 2-3 раза переделывать. Потому, что постановшику задач глубоко пофигу на то, сколько раз будет переделываться работа, а Заказчик сам часто не знает что ему нужно и связи с ним нет.

Если в такой ситуации изучать индексы, ковыряться в носу и медитировать, то обычный отчет будешь делать месяц.

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

"Если в такой ситуации изучать индексы, ковыряться в носу и медитировать, то обычный отчет будешь делать месяц"

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

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

(141) знаний у меня достаточно для решения задач, которые ставит передо мной работодатель. Это подтверждает мой успешный стаж работы этой области в течении 14 лет.

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

Че тут думать, тут прыгать надо...

(143) Ну как бы у меня тоже 10 лет опыта, и что с того? Я точно знаю, что я многого не знаю, но стремлюсь это устранить. Гонор ещё никому не помогал.

(145) сколько помню хадгенога на мисте - вечно в душу нагадить желает.

В этом году мне будет 9 лет :-0

А помню его почти с основания мисты

** помнят! чертяки!

(143) чтобы обслуживать/дописывать базу ларька конечно же ничего особого не нужно :)

(150) я бы твою базу ларька дописывал красиво. Там делать некуй и переписывать код по пять раз не надо.

(151) Я не понял, ты гордишься, что код по 5 раз переписываешь?

Я основной код наших доработок, оставшихся за предыдущими прогами (связаный с проведением РТУ) переписывал раза 3. Каждый раз считая, что вышла мммм, конфетка.

(151) у меня нет базы ларька :( но, тебе бы доверил :)

(152) есть такая работа, платят от 200 тыр. Но главное условие: будь готов выкинуть в мусорку результат недельной работы и стараний и начать заново.

(155) Депутат?

Диллема...
Продать совесть за 200 тыр.

Встречайте новый роман Д. Донцовой "Последнее искушение 1Сника", "Продажный код", "Черный властелин 1С. Годы молодости".

вот жеж... вон оно че, Михалыч! надо видимо, брать толстую книжку по sql и читаааать....

так в итоге то как лучше сложные условия использовать в "ГДЕ.."?

Вот еще что меня всегда волновало в условиях запроса. Есть выражение А ИЛИ Б. Причем мы заранее знаем, что А верно в 99 процентов случаев, а Б только в 1 проценте. Я верно понимаю, что порядок логических выражений имеет роль и "А ИЛИ Б" отработает быстрее, чем "Б ИЛИ А" ???

(158) нет, порядок написания не важен.

(159) уточнение - в большинстве случаев не важен, планировщик запроса сам по своей статистике разберется, какое условие лучше проверить первым. Но иногда ошибается, и тогда лучше указать ему хинт. Но это на самом SQL, в 1С это никак не сделать, к сожалению.

(158) Книжку по SQL, конечно же, лучше почитать. Можно также MSDN по SQL серверу поизучать, документацию на postgre и т.п. Все это может помочь при написании запросов в 1С, хотя на SQL-сервер они порой приходят в таком изуродованном виде, что... Впрочем, разработчиков платформы трудно в этом винить, поскольку трансляция языка 1С-эскуэл в нормальный несколько нетривиальный процесс, как мне кажется.

Главное, чтобы после замены ИЛИ на объединение не получилось, что сервер выполняет вместо одного полного сканирования несколько.