BlazkowiczВыборки далеко не всегда имеют единственную строку как результат.
Не понял утверждения. База шлет клиенту не по одной строчке, а как клиент захочет ( https://docs.oracle.com/javase/7/docs/api/java/sql/Statement.html#setFetchSize(int)) в оракле значение по-умолчанию - 10. Если знать что резалтсет заведомо узкий, то строки можно упаковывать плотнее. В оракле разница между 1 и 10 на запросе "select '100 chars' from dual connect by level < 1000000" - порядок, что как бы ожидаемо. Причем разница получается исключительно засчет сети.

BlazkowiczАндрей Панфиловт.е. между 1 и 10 разница есть, а между 5 и 10 уже нет?

Не понял связи. Мой посыл в том что затраты на поиск и чтение не сопоставимы с разницей в передаче по сети 5 и 50 колонок.
У вас не предыдущей странице был вопрос: "Вы к нам на машине времени прямиком из 90х?". К вам вопрос: а вы из какого года прибыли? из 2000? Сейчас скорость IO у СУБД перекрывает скорость сетевых интерфейсов. Про поколоночное хранение в СУБД слышали что-нибудь? А про InMemory database?

BlazkowiczОбоснования не обнаружено. Вы указываете на то что разница должна быть. Таки - да, она есть. Но вы игнорируете тот факт что на фоне всех остальных накладных расходов на выполнения запроса ею можно принебречь.

Андрей Панфиловразница в скорости выборки между 2 и 20 колонками - 10%, а между 50 и 100 - уже 100%, по CPU тоже разница видна невооруженным взглядом: http://screencast.com/t/h6kM7yDx
Ну, таблицы на 50+ колонок живут в легаси БД, где таки да, есть смысл сужать выборки. А в пределах до 50 я таких значений в разнице не наблюдал в своих тестах в SQL Server. Но дело давно было.Так есть разница или нет? Может просто MSSQL не так хорошо работает как хотелось бы?

BlazkowiczМы всё ещё говорим об ORM. Вычитали RS в объекты и закрыли. Открытым в серверных решениях его держать нет смысла.И какой вывод я из этого должен сделать? Резалтсет читается некоторое время, можете с ходу сказать сколько запусков GC эти объекты переживут?

Blazkowicz,

от вас какие-то цифры можно будет дождаться или нет? я свои уже привел, при кручении правильных ручек только в жаве, разница между получением 2 и 20 колонок из базы - 4 раза, а ваши 10G - это всего лишь скорость линка, чтобы она в перфоманс материализовалась нужно еще ручки крутить.

BlazkowiczУгу. Выкинули IO. Померяли не понятно что. Вышел синтетический тест, оторванный от реальности.
Вам никто не мешает описать "правильную" методику, только при этом не забывайте, что мы как бы в 2016 году живем, и воткнуть 512Gb памяти в СУБД особых проблем не составляет (хотя вру, сейчас писюки под 12Tb идут).

BlazkowiczОх, уж эти детские мечты про "перформанс", который нужен гораздо меньше чем качественный, открытый к изменениям код и заложеная в архитектуру масштабируемость.

Интересно, чем это заворачивание "мусора" в @Embeddable/Embedded начало влиять на качество кода и открытость к изменениям?

Blazkowicz10 GB хватит для нормального взаимодействия любой RBDMS и middle tier реализованного без откровенных косяков. Можно ничего особо и не крутить. А когда нужно больше, то чаще встаёт вопрос про то подходит ли для этой задачи RDBMS в принципе.
Возьмите для начала любой сетевой калькулятор, например https://www.switch.ch/network/tools/tcp_throughput/, и посмотрите какой throughput выдает TCP на 10G линке.

BlazkowiczВы о чем вообще???вам лучше знать, про "качественный, открытый к изменениям код и заложеная в архитектуру масштабируемость" писал же не я, соответственно и возник вопрос каким образом сужение projection влияет на качество кода.

Petro123,

утверждения "для ваших 200 записей вы видимого профита не получите" и "ширина выборки на производительность имеет совершенно никакого влияния" несут совершенно разную смысловую нагрузку, при этом второе не только неочевидно, да еще и нелогично, и, соответственно, требует хоть какого-то стройного подтверждения, а не чего-то в духе: "в жаву мы воткнем 512Gb памяти чтобы не париться из-за объемов, а в базу не будем - пусть страдает от I/O"

llemingоб этом уже говорилось что чтение построчное (Postgres) разницы нет для DB читать одну колонку или все сразувы бы почитали про инструмент с которым вы работаете прежде чем утверждать что разницы нет: https://www.postgresql.org/docs/9.5/static/storage-toast.html

llemingсразу второе предложение
Therefore, it is not possible to store very large field values directly.

тут уже где то говорилось что если large fields то делать их lazy.Давайте с первого предложения, а не со второго. Что там происходит если строка таблицы в блок не влезает?

llemingPostgreSQL uses a fixed page size (commonly 8 kB), and does not allow tuples to span multiple pages

дальше что?В вашем инструменте принципиально нельзя создать "широкую" таблицу (больше 8K) или-таки можно, но при этом будет использоваться TOAST вне зависимости от того есть в таблице "large fields" или нет?