вадяпотому что java - это байткод, а coalesce - это машинный код.
опять мантры про байт код.
вадядаже если использовать


всё равно двойное обращение к rs.getString(4)...

уже лучше



вадяcoalesce вернёт то что требуется.
rs.getString создаст строку, но разве если в запросе есть coalesce то rs.getString(4) не понадобиться ? Можете пример привести без rs.getString(4) ?


Как это фраза соотносится с производительностью. Если используется coalesce в запросе то rs.getString(4) будет работать по другому ежели в запросе этой функции нет ? Напоминаю вашу претензию, проблемы с производительность из за rs.getString в цикле, что этот вызов будет создавать строку, т..е если используем coalesce то rs.getString перестанет создавать строку?, или rs.getString вообще не понадобится ?


Я обращал внимание что в случае coalesce, в связи с универсальностью этой фукнции, инструкций для вычисления результа будет больше на уровне бд. Если это не видно значит этого нет ? Если для Вас это не наглядно то можно посмотреть код postgres.


вадятут нет неприязни, тут есть наблюдение, когда прошёл жизненную школу по работе с базами, очень видно - что не так делается. Очень противно, когда своё незнание в предмете скрывается за громкими словами... Когда настаивают на преимуществах хибера, не представляя что он делает. К примеру при получении данных из селекта хибер сначала заполняет лист, и только потом отдает его на использование. а зачем? когда можно напрямую использовать данные из селекта. это и затраты на память и на время. ладно когда с 10 записей, а когда 1000?
А можно вообще jvm в процессе postgres в одном адресном пространстве запустить и сразу после чтения с диска передавать указатель на то куда все считалось, еще будет быстрее. Зачем заполнять всякие буферы, передавать кудато, сериализовать туда и обратно ну зачем. На деле же все проще, требуется отдать пользователю за 100мс, какая разница hibernate там или чистый jdbc.


вадясистема должна работать быстро. это основное.
программист должен уметь написать так чтоб работающий быстро код был доступен для лёгкого понимания, и он должен понимать любой код. а писать код с ориентацией на слабых сопровождающих - шаг в пропасть.

Вот если ко все машинам основное требование было ездить быстро, страшно было бы на дорогу выйти. Бесконечно быстро это бесконечно дорого. Тут опять треугольник надежно, быстро приемлемо по затратам, треугольник крутите туда куда надо.

Опять же основная претенция на категоричность фразы в "БД быстрее наитивнее оптимизированней"

Озверинвадяпропущено...
не совсем так. у субд есть ключи какой объём данных они возвращают через буфер. и заполняют его по мере чтения из него.
поэтому находясь в начале результсета невозможно узнать количество записей.
как только дошел до конца результсета - все данные в памяти, а если ты их использовал -незачем хранить.

боюсь вы даже про разные кэши ведете речь, у вади кэши субд, а у вас кэши в jdbc драйвере.

вадяrs.getString("xx") вернёт "0"
"0" это же строка создается да еще и в цикле.

Почему


быстрее чем


вадя что-то всё намешано в кучу
ну вам показалось медленно, что не нужна прослойка jpa, можно сразу из resultset данные передавать клиенту. Я описал вариант и выкинуть прослойку resultset и запускать в едином адресном пространстве так будет еще ближе к БД вообще не придется ничего передвать копировать сериализовать, правда так никто не делает. Это правда сильно сложнее будет.

Вы остановились на своем уровне, те кто работает с jpa остановились на своем.

вадяllemingВот если ко все машинам основное требование было ездить быстро, страшно было бы на дорогу выйти. Бесконечно быстро это бесконечно дорого. Тут опять треугольник надежно, быстро приемлемо по затратам, треугольник крутите туда куда надо.для конечного пользователя главное чтоб система работала быстро, и ему пофигу что там внутри. вы же пропагандируете - главное чтоб красиво было написано, а как работает - лишь бы работало.
в итоге приходится ждать пока операторы загрузят инфу и слышать : "Подождите, ваши данные загружаются"

чтож вы все перевираете то
оператору нужно нужно отдать данные в 100мс дальнейнее улучшение бесмысленно. Неважно за 10мс или за 10мкс или 10нс он все равно не заметит.

вадяLeonid KudryavtsevИзвестны кому?
Если не известны Вам, то это не значит, что они вообще не известны ))) Может, кто нибудь знает и помалкивает. Т.к. действительно - раз в __некоторых__ случаях грузятся все данные, то в этих счастилвых случаях, кому-то кол-во записей должно быть известно )))как только получены данные - и указатель находится в начале - нельзя узнать сколько строк в результсете, необходимо "указатель" переместить на последнюю запись только тогда можно узнать количество строк в результсете

Ссылка была указана на jdbc драйвер postgresql. Есть причины недоверять разрабам драйвере все ли данные сразу в resultset помещаются или нет?

Во первых это поведение не гарантируется все производителями БД. Те кто делал postgres сделал так как сделал. Те кто писал jdbc spec сделал так чтобы можно было расширить. Так в случае Postgresql всего ли частная имплетентация.

lleming нельзя узнать сколько строк в результсете
Можно (postygresql), возьми и через reflection дерни. Только решение это не jdbc. И только для конкретного драйвера.

вадяllemingСсылка была указана на jdbc драйвер postgresql. Есть причины недоверять разрабам драйвере все ли данные сразу в resultset помещаются или нет?я работал с несколькими субд и во всех так.
проверь - перед первым next сколько строк вернул резульсет
Озверинвадя,ты сам себя презираешь? Ты ж не продемонстрировал пока ничего.показывал, больше не буду

Перед тем как отписать проверил. Все ок.

вадяllemingМожно (postygresql), возьми и через reflection дерни. Только решение это не jdbc. И только для конкретного драйвера.хорошее уточнение....

Еще уточнение, это не гарантируется. Нужно автокомит отключить и настроить тип result set это раз.
Два нет никаких гарантий что через неделю в новом релизе драйвера это поведение поправят в "нужную" сторону.