Разница безусловно будет.
Вопрос поставлен несколько некорректно. PostgreSQL сам не реализует ни один из указанных языков, кроме PL/pgSQL. Для остальных языков используются родные библиотеки из состава самих языков, поэтому разница в производительности будет определяться прежде всего реализацией самих языков, а не возможностью их использования в PostgreSQL.
Также по моему глубокому убеждению, если вы не будете использовать эти языки в PostgreSQL для выскопроизводительных вычислений, то соответственно и разница в быстродействии будет не такая уж значительная.
А если выполнять высокопроизводительные вычисления, можно дать какие-то рекомендации?
Присматриваюсь к Python, потому что для него уже есть готовые модули для моих задач.
Будет ли ощутимая разница, если выгружать данные на клиента и вычислять на нём, или вычислять прямо на сервере?
Правильно ли я понимаю, что PostgreSQL хранит только текст, а не компилированный/транслированный код?
Так проверьте, кто не даёт? Напишите маленький тест, который в чём-то симулирует те задачи, которые вы будете решать и прогоните его. Кому кроме вас лучше знать, что у вас там будет?
Если хотите моё мнение - надо использовать сервер СУБД именно как СУБД, а не для посторонних дел. Хотя набор функций довольно велик, но всё-таки первоначальная задача СУБД состоит в поиске информации по заданному набору условий, а не в обсчётах каких-то там данных.
Кто знает, возможно, для вас лучшей архитектурой будет установка дополнительного сервера приложений между клиентом и сервером PostgreSQL. Это позволит выполнять необходимые обсчёты на сервере приложений, а также огранизовать (в случае необходимости) какой-либо кэш запросов с сервера СУБД.
> Правильно ли я понимаю, что PostgreSQL хранит только текст, а не компилированный/транслированный код?
Я так понимаю: в момент создания хранимой процедуры - она компилируется и компилированный вариант сохраняется в СУБД вместе с исходником.
Разница безусловно
Разница безусловно будет.
Вопрос поставлен несколько некорректно. PostgreSQL сам не реализует ни один из указанных языков, кроме PL/pgSQL. Для остальных языков используются родные библиотеки из состава самих языков, поэтому разница в производительности будет определяться прежде всего реализацией самих языков, а не возможностью их использования в PostgreSQL.
Также по моему глубокому убеждению, если вы не будете использовать эти языки в PostgreSQL для выскопроизводительных вычислений, то соответственно и разница в быстродействии будет не такая уж значительная.
А если выполнять
А если выполнять высокопроизводительные вычисления, можно дать какие-то рекомендации?
Присматриваюсь к Python, потому что для него уже есть готовые модули для моих задач.
Будет ли ощутимая разница, если выгружать данные на клиента и вычислять на нём, или вычислять прямо на сервере?
Правильно ли я понимаю, что PostgreSQL хранит только текст, а не компилированный/транслированный код?
Так проверьте, кто не даёт?
Так проверьте, кто не даёт? Напишите маленький тест, который в чём-то симулирует те задачи, которые вы будете решать и прогоните его. Кому кроме вас лучше знать, что у вас там будет?
Если хотите моё мнение - надо использовать сервер СУБД именно как СУБД, а не для посторонних дел. Хотя набор функций довольно велик, но всё-таки первоначальная задача СУБД состоит в поиске информации по заданному набору условий, а не в обсчётах каких-то там данных.
Кто знает, возможно, для вас лучшей архитектурой будет установка дополнительного сервера приложений между клиентом и сервером PostgreSQL. Это позволит выполнять необходимые обсчёты на сервере приложений, а также огранизовать (в случае необходимости) какой-либо кэш запросов с сервера СУБД.
> Правильно ли я понимаю, что PostgreSQL хранит только текст, а не компилированный/транслированный код?
Я так понимаю: в момент создания хранимой процедуры - она компилируется и компилированный вариант сохраняется в СУБД вместе с исходником.