данные забивает сразу в память, а при несортированном получает пачками и не забивает.
Это стандартное поведение для TCP протокола? Есть ли пути обхода? Кто сталкивался?
это все не так. Что такое "забивает сразу в память"
Есть 2 VIEW идентичные. несортированный и сортированный Сортированный - 500мб хипа отжирает при селекте Несортированный - 170мб
хипа? в go? в смысле на клиенте КХ или сервере КХ?
Память отжирается на клиенте, именно при запросах в сортированные view
это странно, разница только в том с какой интенсивностью КХ возвращает. Просто для сортированного результата ответ возвращается целиком, а для не сортированного стримится, но клиенту должно быть пофиг. Может в го драйвере можно размер блока возвращаемого настроить?
Подебажил немного, он при чтении берет размер блока из TCP ответа похоже, При сортированном запросе размер блока 65505, соответственно целиком читает 65к записей в память. откуда может браться это число? Может какая настройка на стороне КХ?
max_block_size можно поменять для сессии, профиля, запроса
в общем-то в 99% случаев КХ возвращает блоки по 65505 строк и оперирует внутри себя тоже, раньше было 65536 но выяснилось что перформанс при 65505 в среднем выше из-за каких-то оверхедов.
Обсуждают сегодня