Вполне вариант. Только как бы гарантировать, что купленный китайский пульт будет поддерживаться? в списке поддерживаемых девайсов у пульта всевозможные именитые бренды…
А на CPack не смотрели? Это средство, конечно, не позволит на gentoo x64 собрать пакет для Debian'а 32, но он един для всех платформ. Теоретически, если собрать ферму нужных серверов (можно в виртуалках, к примеру) и обвязать их скриптами для генерации пакетов по CPack'овской конфигурации — должно сработать…
Это я все понимаю. Но я надеялся, что существуют какие-нибудь фермы сборки или инструменты, с помощью которых их можно построить… В основном для бинарных дистрибутивов (с исходниками зависимости сложнее).
Он создает для того окружения, в котором сам установлен. То есть, чтобы мне создать пакеты, к примеру, для 32 и 64 разрядных систем, мне нужны обе установленные системы с установленными checkinstall.
ToSHiC так как можно работать только в рамках одной транзакции, то обязательно придется использовать трехзвенную архитектуру с демоном. Поэтому решение EndUser с последовательностью тоже имеет место, потому как не требует дополнительных прослоек между БД и хостами.
ToSHiC Наконец-то нашел в документации то, что требовалось. Просто нужно действовать в рамках одной транзакции и использовать DECLARE CURSOR и FETCH. Правильно я понимаю? Товарищ strib наверное говорил о том же?
Вместо OFFSET лучше использовать > и <? Это не будет медленней?! Я думал OFFSET и LIMIT — это внутренняя штука СУБД по которой он быстро может встать в середину таблицы и выплюнуть некоторое количество данных…
EndUser, да ORDER BY я тупо забыл написать в вопросе — естественно использую. Попробую serial с primary key — может действительно получу выигрыш. Отпишусь как все прошло. Спасибо за решение с sequence.
EndUser, то есть если pk имеет тип serial и индекс primary key, а id тип bigint и индекс поумолчанию, то
SELECT id FROM table OFFSET K LIMIT N ORDER BY pk будет работать быстрее чем просто
SELECT id FROM tabke OFFSET K LIMIT N ORDER BY id?
EndUser, id — это пример, это не primary key, по своей природе он не может идти последовательно и быть заменен счетчиком либо какой-то генерирующей функцией. Иначе зачем мне эта таблица?!
Повторюсь. Счетчик в порядки и идея хорошая — можно было бы не реализовывать демон. Проблема в тормозах запроса «SELECT id From table OFFSET K LIMIT N» с определенного K. Или надо решить проблему этих тормозов или думать над другим решением…
EndUser, да, решение со счетчиком работает. Но проблема в скорости. Я же писал, что реализован демон, который работает также как ваш счетчик, но забирает во внутренний буффер сразу N строк. Проблема в том, что SELECT… OFFSET K LIMIT N сильно тормозит с определенного К.
EndUser, насчёт счётчика. Чем N select'ов вида «OFFSET K LIMIT 1» быстрее одного «OFFSET K LIMIT N»? При таком подходе не нужен демон — это плюс, но прироста скорости так не добиться.
