Набір витрат на процедурні мови PostgreSQL (plpython / plsql / pllua…)

Я намагаюся знайти інформацію про функції, визначені користувачем PostgreSQL, у виконанні процедурних мов для завдань у режимі реального часу.

1. Як вони порівнюються з вбудованими функціями?
2. Чи є різниця (накладні витрати) на те, як Postgres викликає / керує функціями plpython vs plpgsql vs pllua (мене цікавить інтеграція Postgres / контекст / передача даних, а не сам VM)?
3. Чи великий контекст чи великий контекст? Чи можу я використовувати його для відображення даних у режимі реального часу (скажімо, 1000 запитів / с))
4. Чи є якась користь від написання визначених користувачем функцій у plpgsql, ніж у інших pg / мові? Щодо документації, вони перераховують переваги, але я думаю, що вони застосовуються до всіх процедурних мов postgresql.

Супутні висновки:

• Швидкість мов PL для нетипового використання
• Продуктивність мови функцій PostgreSQL: C проти PL / PGSQL

1. UDF в інтерпретованих мовах завжди набагато повільніше, ніж UDF, написані на C або вбудовані функції, всі інші речі однакові.

2. Кожна мова пов'язана з різним кодом для підключення PostgreSQL до мови, з різними ступенями оптимізації, різними способами передачі деяких типів даних тощо. Отже, варіації, безумовно, є. Це не повинно бути величезним, якщо ви не передаєте тип даних, який обробляється однією мовою, ніж інша, наприклад, один передає a hstoreяк рядок, а інший перетворює його в a dict.

3. Незрозуміло, що таке "контекст". Чи можете ви використовувати його для "відображення даних у режимі реального часу" ... ну, це залежить від того, що функція виконує, і якщо вона досить швидка на сервері, на якому вона працює, для клієнтів, до яких вона займається, та ваших вимог. Як довгий шматок струни? Орієнтир.

4. PL / PgSQL простіше писати та пропонує швидший доступ до SQL. Як правило, краще, коли вам потрібно обернути трохи логіки навколо багатьох SQL. Математичні операції та складні алгоритми дуже повільні, тому слід уникати чисто обчислювального коду в PL / PgSQL, коли це можливо, на користь C або швидшої мови процедури.

Прискорення при повторній реалізації PL / PgSQL-коду в C можуть змінюватися від незначного до понад 1000 разів. Все залежить від того, що насправді робить код.

(Цей різновид запитань не дуже підходить для обміну стеками, оскільки важче отримати остаточну відповідь)

це досить важко сказати. це дійсно залежить від того, що ти робиш. наприклад: PL / pgSQL є чудовим, якщо у вас є великі оператори SQL - він дійсно божевільний, якщо у вас є всі види розгалуження, управління підрядками та все таке.

ви дійсно повинні перевірити від випадку до випадку.

Чи великий контекст чи великий контекст? Чи можу я використовувати його для відображення даних у режимі реального часу (скажімо, 1000 запитів / с))

Продуктивність залежить від обладнання та складності ваших функцій. Я створив прилад, який працював на невеликому 12-ядерному сервері та FusionIO-картці (загальна вартість 10000 євро) і робив близько 2500 транзакцій в секунду з 20 одночасними користувачами. Кожна транзакція викликає 29 збережених процедур для обробки даних та повернення корисної інформації клієнту. Деякі функції виконують лише один запит, інші - кілька запитів. Загалом він виконує близько 200000 операторів INSERT, SELECT та UPDATE за секунду.

Це все написано в PL / SQL, PL / pgSQL та PL / PerlU. І я впевнений, що система може працювати ще швидше, коли (деякі) функції переписуються на C.

Найбільшу продуктивність цього пристрою отримує карта SSD. На одному диску, що обертається, ми ніколи не отримаємо цієї продуктивності. Дешеві SSD-накопичувачі також виходять з ладу, він працює протягом години (через кешування рейд-карти), а потім закінчується гра. FusionIO-карта - дорога, але дуже хороша інвестиція, коли ви зобов’язані IO.