Привет!
Положим, есть таблица, в ней товар, показатель (то, что надо) и состояние показателя (или товара) - задача на самом ставится в общей постановке. Надо отсортировать табличку по коду товара и выбрать записи с НомерСтрокиНач по НомерСтрокиКон + условия.
Я воспользовался статьей в базе знаний
http://kb.mista.ru/article.php?id=703
И написал это
ВЫБРАТЬ ПЕРВЫЕ 31415926
    ТРегСведа.Номенклатура КАК Номенклатура,
    ТРегСведа.Номенклатура.Код КАК НоменклатураКод
ПОМЕСТИТЬ ПОЗИЦИИ
ИЗ
    РегистрСведений.Некоторый КАК ТРегСведа
ГДЕ
    ТРегСведа.Номенклатура.ЭтоГруппа = ЛОЖЬ
    И ТРегСведа.Номенклатура.Родитель = &Родитель

УПОРЯДОЧИТЬ ПО
    ТРегСведа.Номенклатура.Код

ИНДЕКСИРОВАТЬ ПО
    НоменклатураКод,
    Номенклатура
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ПОЗИЦИИУПОРЯДОЧЕННЫ.НомерСтроки,
    ПОЗИЦИИУПОРЯДОЧЕННЫ.Номенклатура,
    ТРегСведа.ТоЧтоНамНадо,
    ТРегСведа.Состояние
ИЗ
    (ВЫБРАТЬ
        КОЛИЧЕСТВО(ПОЗИЦИИ1.НоменклатураКод) КАК НомерСтроки,
        ПОЗИЦИИ.НоменклатураКод КАК НоменклатураКод,
        ПОЗИЦИИ.Номенклатура КАК Номенклатура
    ИЗ
        ПОЗИЦИИ КАК ПОЗИЦИИ
            ВНУТРЕННЕЕ СОЕДИНЕНИЕ ПОЗИЦИИ КАК ПОЗИЦИИ1
            ПО ПОЗИЦИИ.НоменклатураКод >= ПОЗИЦИИ1.НоменклатураКод
    
    СГРУППИРОВАТЬ ПО
        ПОЗИЦИИ.Номенклатура,
        ПОЗИЦИИ.НоменклатураКод) КАК ПОЗИЦИИУПОРЯДОЧЕННЫ
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.Некоторый КАК ТРегСведа
        ПО ПОЗИЦИИУПОРЯДОЧЕННЫ.Номенклатура = ТРегСведа.Номенклатура
ГДЕ
    ТРегСведа.Состояние = &Состояние
    И ПОЗИЦИИУПОРЯДОЧЕННЫ.НомерСтроки МЕЖДУ &НомерСтрокиНач И &НомерСтрокиКон
УПОРЯДОЧИТЬ ПО
    ПОЗИЦИИУПОРЯДОЧЕННЫ.НомерСтроки
Вот теперь в предположении, что выборки будут частые и повторяющиеся, данные тоже будут часто обновляться ... вопрос - это самое быстрое, что можно сделать?
Второй: может в 8.3 уже используются CTE и это как-то повлияло на тексты запросов? Статье-то уже лет сколько!

"ТРегСведа.Состояние = &Состояние" надо вверх перенести ...

Зачем "ПЕРВЫЕ 31415926 "?
И еще лично мне как-то не нравится внутреннее соединение с подзапросом. Нестабильная конструкция.

Да и вообще сам запрос как-то не нравится. Не воспринимается без нормальных имен таблиц.Он хоть работает правильно?

(2) Работает правильно, в консоли сейчас гоняю.
Тут небольшая хитрость: я точно знаю количество элементов под Родителем и поэтому потом делаю
СтрЗаменить(Запо.Текст, "31415926", Формат(ВсегоВКатегории, "ЧН=; ЧГ="));
А вот если бы я это не знал, то не мог бы выбрать во временную таблицу с упорядочением, мне бы пришлось придумывать цифру - которая за время актуальности программы гарантировано переароет количество элементов  в папке.
Нормальные имена таблицы - ну пусть в регистре хранятся двоичные данные картинок и состояние большая/ маленькая.

(2) Без первых - нельзя упорядочивать.

Нумеруй в постобработке.

(4) В постобработке даже нумеровать не надо - в ТЗ все пронумеровано. Если выборку использовать - тоже.

А если РегистрСведений.Некоторый в ВТ?

(5) Не знаю, сколько там записей.
Но если действитель 31415926, то конструкция
ВНУТРЕННЕЕ СОЕДИНЕНИЕ ПОЗИЦИИ КАК ПОЗИЦИИ1
ПО ПОЗИЦИИ.НоменклатураКод >= ПОЗИЦИИ1.НоменклатураКод
будет надолго вешать сервер.
Если есть возможность, лучше нумеровать после выборки. Или даже хранить номера в отдельном ресурсе регистра.

(6) "ПОМЕСТИТЬ ПОЗИЦИИ" - они и идут в ВТ.
(7) Это классика из книги знаний. Не уверен, что выгрузка в таблицу или создание выборки будет быстрее.
А вот если они такие конструкции в SQL CTE научились переводить, то быстрее ничего и не будет.

(0) 1. CTE не появились.
2. НомерСтрокиНач и НомерСтрокиКон что нумеруют? Судя по вашему запросу они нумеруют только коды номенклатуры.
3. Если "НомерСтроки" не выводить, то можно написать заметно быстрее.

(9) Запрашивающий ничего не знает про коды, пока коды к нему не придут. Он знает, что есть 300 позиций и знает, что не стоит запрашивать их все сразу, поэтому загружает их по кускам: с 1 по 15, с 16 по 30 ....

(10)Ну тогда решение можно и другое применить:
Вариант 1: поступить, как сама 1С и передавать в запрос "ключ" последней строки. Можно посмотреть трассировкой или ТЖ при просмотре форм документов/справочников.
Вариант 2 (если почему-то ключ нельзя передать):

ВЫБРАТЬ ПЕРВЫЕ 10 // сколько строк надо
    Таблица.Поле1,
    Таблица.Поле2,
    Таблица.Поле3
ИЗ
    (ВЫБРАТЬ ПЕРВЫЕ 1000 // номер последней строки
        Таблица.Поле1,
        Таблица.Поле2,
        Таблица.Поле3
    ИЗ
        (ВЫБРАТЬ
            ТвойРегистр.Поле1 КАК Поле1,
            ТвойРегистр.Поле1.Код КАК Поле2,
            ТвойРегистр.Состояние КАК Поле3
        ИЗ
            РегистрСведений.ТвойРегистр КАК ТвойРегистр) КАК Таблица
    УПОРЯДОЧИТЬ ПО
        Таблица.Поле2,
        Таблица.Поле3) КАК Таблица
УПОРЯДОЧИТЬ ПО
    Таблица.Поле2 УБЫВ,
    Таблица.Поле3 УБЫВ

(10) Жесть.
Однозначно вариант 10.1

Сортируй по номенклатуре, выбирай Первые 300, где Номенклатура>&ПоследняяВыбраннаяНоменклатура

(2) это для "Упорядочить По". Наверное, раньше это было реализовано как вложенный запрос, вот и осталось исторически

(11), (12) и (13) Спасибо, свет пролили.
"Номенклатура>&ПоследняяВыбраннаяНоменклатура" - упорядочивать надо по коду.
Поэтому, сперва хоть в подзапросе, хоть где будет соединена таблица регистра с таблицей справочника и надо будет проиндексировать.
Значит борьба за время произойдет во втором запросе, если нет какого-либо "чуда" SQL.
Вероятно надо сперва написать самый быстрый SQL для такой задачи, а потом смотреть в профайлере насколько запрос 1С будет похож на этот "быстрый".
Последний код (последнюю запись) можно передавать только для постраничного просмотра списка, а если я нарисую список страниц или алфавитную линейку? Тут все ж  номера важней.

(0)а зачем это?
имитация динамического списка?

(16) Ну, да. Только не для 1С.