Краш-курс по интерфейсам в Go

В Java интерфейс может содержать только константы (final variables), а не переменные. Так что никто поведение и данные не мешает.

Критическая уязвимость в ряде Java Application Server

Вы правы — я глупость написал.

Критическая уязвимость в ряде Java Application Server

Либо я чего-то не понимаю, но что мешает взять любой протокол, который использует сериализацию/десериализацию, посмотреть какие классы ходят и сделать override default constructor/readObject и там написать что надо. Только нужно чуть больше работы, чем просто взять exploit для commons-collections

Open source сервер онлайн-чатов на Java

А зачем вообще иметь различные вьюхи в зависимости от языка? Используйте resource bundles и показывайте лейблы и сообщения без того, чтобы клонировать разметку

Open source сервер онлайн-чатов на Java

Ой, github.com/edolganov/live-chat-engine/search?utf8=%E2%9C%93&q=isThreadLang_EN — что это? Зачем хардкодить?

Spring Boot: от начала до продакшена

Насколько я помню, вот это все:

config.addDataSourceProperty("cachePrepStmts", "true");
config.addDataSourceProperty("prepStmtCacheSize", "250");
config.addDataSourceProperty("prepStmtCacheSqlLimit", "2048");
config.addDataSourceProperty("useServerPrepStmts", "true");

для MySQL драйвера, а не для Postgres

Упрощая жизнь c Django

Я так понял план неправильно считает постгре, и то как Вы написали-они поправили это дело. Mysql строит не весь план в случае prepared statements. Так что то, что preparedstatements медленные в постгре можно отнести к недальновидности разработчиков постгряшного оптимизатора.

Что касается юзкейсов — Вы почему то опустили селекты, которые в данном случае намного интереснее. Если у Вас селект в полстраницы — его разбирать уже не так быстро.

Упрощая жизнь c Django

Ну у вас получается разобраный запрос во внутреннем представлении и план на основе синтаксиса запроса. Уже будет выигрыш. А если запрос большой? Интерпретация его каждый раз тоже небесплатна

Упрощая жизнь c Django

Хм, очень странно такое поведение Postgres-а. Ересь какая-то. Просто очень плотно работал с oracle, для которого неиспользование PreparedStatement-ов приводит к очень грустным результатам. Может просто не надо делать оптимизацию на уровне компилирования запроса, а уж если очень хочется — строить общий план, а потом корректировать на основании полученных данных. По крайней мере мы избегаем компиляции запроса, что для сложных запросов даст припрост.

Упрощая жизнь c Django

Я неверно выразился — под планом выполнения имел ввиду разобраное SQL выражения. Это еще не план. Но уже и не исходный SQL. Т.е. в случае server-side prepared statement второй раз не придется заниматься разбором sql-а, так как внутреннее представление уже есть

Упрощая жизнь c Django

Откуда такая информация? Как по вашему происходит выполнения запроса в СУБД?

Упрощая жизнь c Django

Запросы будут бегать быстрее, ведь не надо будет каждый раз строить план выполнения запроса

Упрощая жизнь c Django

Ясно, получается, что в случае MySQL и MySQLdb мы не сможем использовать server-side prepared statements

Упрощая жизнь c Django

А разве django не использует preparedStements для запросов?