Доброго времени суток!

Определенное время уже мучает один алгорим:

Необходим быстрый поиск из документа, предыдущего документа.

Делаю через запрос и виртуальную таблицу СрезПоследних(&ДатаК, НужныйМнеОтбор),
но данный вариант медленоват, т.к. потом из этого набора делать поиск документа по максимальной дате или же сортировать и брать первый.

Может кто уже проходил эту траблу и знает более скоростной алгоритм поиска?

Выбрать Первые 1 Из РегистрСведений.РегистрСведенийГде Период < &МоментВремени Упорядочить по Период Убыв

платформа 8.1

Fragster дал ответ, когда ещё вопрос не был закончен ;)

(1) делал и такой "финт ушами", скоростнее нет вариантов?

(4) ты фанат микрооптимизаций или есть обоснования из профайлера?

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

(6) но вообще - да, есть скоростнее. Создать и поддерживать реквизит ПредыдущийДокумент

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

Задача ускорить время заполнения документа, а документ заполняется на основе предыдущего дока.

(8) мои телепатические возможности исчерпали ману. Озвучь задачу полностью. Или хотя бы, в какой момент и у кого тормозит?

(9) все тормоза при автоматическом заполнении документа....
из анализа кода и запросов, выявлены слабые места, а именно запрос который ищет предыдущий документ (а таких запроса два, но с разными отборами)

+(10) перепробовал кучу вариаций запросов, но ниже 8 сек, не получилось спуститься

+(10) основной тормоз при первом заполлнении нового документа, при втором запорлнении время немного падает

Фига себе. Заведи РС и пиши туда последний документ.

(10) а можно поподробней, сколько точно по времени длятся тормоза при заполнении документА?

+(12) при втором заполнении = при повторном заполнении

Покажи-ка запрос, который "8 секунд"

я не верю, что запрос из (1) тормозит. Пусть автор приведет свой вариант.

(16) и (17) в каких единицах измеряет замер производительности? В милисекундах или в секундах?

(18) убил..

(18) публика скандирует "Запрос! Запрос!"

(18) В парсеках

(1) Не взлетит.
(0) АВТОУПОРЯДОЧИВАНИЕ

Данный запрос уже пережил много модификаций, но пока я остановился на этом варианте:

ВЫБРАТЬ
   ПутевойЛист.Период КАК ДатаПЛ,
   ПутевойЛист.Регистратор КАК ПутевойЛист,
   ПутевойЛист.ГосНомер КАК ФизЛицоПЛ,
   ОбработкаПутевогоЛиста.НомерПутевогоЛиста КАК ОбработкаПутевогоЛиста,
   ОбработкаПутевогоЛиста.ГосНомер КАК ФизЛицоОПЛ
ПОМЕСТИТЬ Документы
ИЗ
   РегистрСведений.атпПутевойЛист.СрезПоследних(
           &ДатаК,
           Регистратор.ФизЛицоПервойСмены = &Водитель
               ИЛИ Регистратор.ФизЛицоВторойСмены = &Водитель) КАК ПутевойЛист
       ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.атпОбработкаПутевогоЛиста КАК ОбработкаПутевогоЛиста
       ПО ПутевойЛист.Регистратор = ОбработкаПутевогоЛиста.НомерПутевогоЛиста
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
   МАКСИМУМ(ВЗ.ДатаПЛ) КАК ПериодДок
ПОМЕСТИТЬ МаксДата
ИЗ
   Документы КАК ВЗ
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
   Документы.ПутевойЛист КАК ПутевойЛист,
   Документы.ОбработкаПутевогоЛиста КАК ОбработкаПутевогоЛиста,
   МаксДата.ПериодДок КАК МаксДата
ИЗ
   Документы КАК Документы
       ЛЕВОЕ СОЕДИНЕНИЕ МаксДата КАК МаксДата
       ПО (ИСТИНА)
ГДЕ
   НАЧАЛОПЕРИОДА(Документы.ПутевойЛист.Дата, ДЕНЬ) = МаксДата.ПериодДок

(23) нафига левое соединение и условие в ГДЕ?
чем внутреннее не устроило?

(22) дружище, кури момент времени, там все правильно!
(23) а где там вариант из (1)?

(24) быстрее будет?

(26) 90% за "не будет", потому что виртуальная таблица в качестве той, к которой данные присоединяются

и зачем последние два запроса?
сразу сгруппировать, найти максимум по дате и сравнить в ИМЕЮЩИЕ ?

(25) вариант из (1) был в самом начале.... с него то все и началось

ГДЕ
   НАЧАЛОПЕРИОДА(Документы.ПутевойЛист.Дата, ДЕНЬ) = МаксДата.ПериодДок
условие может и не выполнится никогда - нормально?

(23) проблема в условии к вирт таблице. Вытащи физлица в РС

Регистратор.ФизЛицоПервойСмены - вот эта фишка у вас превращает миллисекунды в секунды.

поставьте эти поля в измерения регистра.
ну хотя бы проверьте, точно-точно у вас на этих реквизитах:
ФизЛицоПервойСмены,ФизЛицоВторойСмены и ОбработкаПутевогоЛиста.НомерПутевогоЛиста стоит галка "Индексировать".

(32) вот то то и оно.... умники до меня в регистре сделали ФизЛицоПервойСмены - СТРОКА!!! Приходится тянуть из ..опы.

(33) какая разница, строка или ссылка? А хаять предшественников - вообще дело неблагородное. Тебе что-то мешает переделать структуру базы под новые задачи?

(34) большая разница.... строить выражение по ссылке на объект или по строке, тем более где указано ФИО (знаешь сколько бывает однофамильцев, одноименцев и одноотчествеников одновремено).
Мне мешает переделать базу, куча документов (около 3-х лет), которые придется либо перепроводить (а перепроводятся они цепочками) либо переписывать алгоритмы из взаимодействия.

Автор. Если у тебя тормозит запрос из (1), то тебе уже ничего не поможет. Только взрывать консерваторию.

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

Все большое спасибо, что посочувствовали.

(35) открою небольшой секрет: ссылка - это строка..

"Мне мешает переделать базу, куча документов (около 3-х лет)"

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