ax2009, 2012. У кого есть опыт работы с paging в Query? Стоит ли этим заморачиваться?

[AndyD]

Цитата:

Сообщение от mazzy

идея в том, чтобы сказать как то SQL'ю что не нужно делать выборку всех-всех-всех записей (а их там может быть сотни тысяч)
а достаточно выбрать первые 1000 или 100... но в случае необходимости, дозапросить еще.

Так Аксапта именно так и делает, что в Query, что в select'е - смотри серверные курсоры

Только, количеством записей, возвращаемых с сервера за раз мы не управляем

И, как правильно выше заметили - это не значит, что SQL не будет напрягаться и хранить результат, если запрос связан с сортировками/группировками/объединениями

[mazzy]

Цитата:

Сообщение от AndyD

Так Аксапта именно так и делает, что в Query, что в select'е - смотри серверные курсоры

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

Цитата:

Сообщение от AndyD

Только, количеством записей, возвращаемых с сервера за раз мы не управляем

угу.
я также в курсе про параметр "размер буфера", который был в конфигурационной утилите прошлых версий.

хорошо, переформулирую вопрос.

в Аксапте 2009 в QueryRun появились методы, которые, судя по названию, позволяют каким-то образом управлять paging. в частности, включать(!!) paging. Ссылки на msdn с примерами я привел в самом начале.

Вопрос: У кого есть опыт работы с paging-методами в Query? Стоит ли этим заморачиваться?

[Vadik]

Цитата:

Сообщение от mazzy

Вопрос: У кого есть опыт работы с paging-методами в Query?

Я использовал (опосредованно) с AIF и его change tracking

Цитата:

Стоит ли этим заморачиваться?

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

Цитата:

Сообщение от Maxim Gorbunov

Если верить вот этому - https://technet.microsoft.com/en-us/.../gg840967.aspx - paging автоматически включается для всех запросов через Query Service

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

Цитата:

If you pass a NULL paging object to the query service, it will not use any paging and will return all records for the specified query up to the maximum record limit

[mazzy]

Цитата:

Сообщение от AndyD

И, как правильно выше заметили - это не значит, что SQL не будет напрягаться и хранить результат, если запрос связан с сортировками/группировками/объединениями

Похоже таки надо сказать несколько слов по поводу сортировок и "напрягаться".
определения:

1. MS SQL хранит данные экстентами, которые состоят из 8Кб-страниц. MS SQL отравляет на диск команду чтения/записи для всего экстента. меньшими порциями MS SQL дисковые операции не делает.
2. данные (record) хранятся в страницах. в каждой 8кб странице умещается несколько строк (record). В частности это означает, что максимальный объем хранения в одной записи в MS SQL - 8Кб
3. индекс - это маленкая запись ))) Да с натяжкой, но в данном случае отличия не важны. Важно, что индексы также хранятся в страницах. столько индексов, сколько уместится на страницу.
4. индексы как правило (Бггг!) отсортированы, и с огромной вероятностью нужные для выборки строки индекса хранятся рядом на одном экстенте.
5. для сортировки MS SQL все равно прочтет с диска экстенты с индексами. Прочтет в любом случае (почти в любом - есть кластерные индексы, есть покрывающие индексы)
6. важно! размер индекса как правило существенно меньше размера записи. обычно индексы содержат поля, сумма которых 60-200 байт. А размер записи с данными легко может составлять 1000-3000 байт. см. vendTrans, см. InventTrans, inventSellement.

собственно проблема:

1. после сортировки, после того, как SQL определил какие записи нужно вернуть, для выдачи результатов в Аксапту MS SQL будет читать экстенты с записями (record). МНОГО. поскольку сами записи больше и раскиданы по разным экстентам, операций чтения данных будет много.
2. поскольку прочитанные данные (record) достаточно объемные, СКЛю нужно очень много "временной" памяти, чтобы хранить полученные результаты и выдать их в Аксапту при следующем QueryRun.next
3. да, вроде должен использоваться курсор... но... есть счетчики и мониторинг в СКЛ, который позволяет увидеть, что большую часть времени для алгоритмов типа "сопоставление" SQL читает экстенты с данными впустую. По крайней мере, у меня сложилось стойкое впечатление, что это так.

еще раз:

• экстенты с индексами все равно будут прочитаны )))) даже не беспокойтесь об этом
• число читаемых с диска экстентов в индексами в разы, на порядки меньше числа экстентов с данными (это сделано специально, в этом и суть индексов )
• беспокоит число операций чтения самих данных, которые SQL готовит для отдачи Аксапте.
• суть paging в том, что SQL хранит у себя ссылки на данные (небольшой объем памяти), а сами данные читает по мере запроса страниц. Причем программист может управлять размером порции, которая готовится SQL'ем и отдается в ответ на запрос.

В операциях, которые делают выборку, по каким-то бизнес-условиям забирают несколько записей из выборки и изменяют выборку (операции типа сопоставление)...
в таких операциях хотелось бы использовать управляемый paging.

собственно отсюда и вопрос - У кого есть опыт работы с paging-методами в Query? Стоит ли этим заморачиваться?
в частности, даст ли гемор с pagin'ом лучший результат, чем автоматическая работа с однонаправленным серверным курсором?