astarsan: (Default)
astarsan ([personal profile] astarsan) wrote2011-11-30 11:55 am
Entry tags:

select only хранимки vs old plain sql

По итогам последних развлечений с sql
У меня сложилась гипотеза что любой скольугодно сложный код на pl/pgsql который
1)не меняет данные и не использует locks/exceptions
2)не работает с курсорами
3)не использует честную рекурсию
UPDATE: 4)не использует EXECUTE так как это очевидно на уровне SQL не реализуется

может быть переделан в виде обычного sql запроса.
Насколько финальный sql запрос будет читаем - вопрос отдельный.
С другой стороны он может оказаться быстрее.

временные таблицы - array[] of records или with подзапросы
циклы - with recursive iterator
if/then - case
вроде ничего из pl/pgsql логики не осталось больше.

Скорее всего это не так но я не смог придумать контрпример.
Так что жду ваши версии select only pl/pgsql кода которые нельзя реализовать обычным запросом.

PS: не надо только 4х страничные хранимки присылать... я думаю если контрпример есть, то он будет коротким и понятным.

[identity profile] hydrobiont.livejournal.com 2011-11-30 05:40 am (UTC)(link)
Или я не понял твой мессадж, или ты только что изобрел тест Тьюринга ;-)

Ну да - посгресовый sql вместе с CTE - тьюринг полный язык и на нем можно сделать что угодно. Ну да - pl/pgsql - тоже вестимо. И что?)

[identity profile] astarsan.livejournal.com 2011-11-30 07:05 am (UTC)(link)
Я как то раньше не думал о том что SQL это "тьюринг полный язык" на самом деле. Потому и возник вопрос.
Я до этого считал что есть куча алгоритмов которые нельзя нормально на sql сделать.

[identity profile] hydrobiont.livejournal.com 2011-11-30 08:08 am (UTC)(link)
Как много нам открытий чудных))

[identity profile] smagen.livejournal.com 2011-11-30 09:28 am (UTC)(link)
По-моему все-таки "тьюринг полный язык" != "можно нормально сделать любой алгоритм". Т.к. "нормально" подразумевает вменяемые время выполнения и объем требуемой памяти, а из-за особенностей реализации языка это может быть не так.

[identity profile] astarsan.livejournal.com 2011-11-30 11:46 pm (UTC)(link)
Через with recursive очень невыгодно по обьему требуемой памяти гонять длинные циклы (там потребление памяти линейное от количества итераций) поэтому любой алгоритм на pl/pgsql с длинными (и тем более с длинным вложенными) циклами если его не удасться переделать на with/join а прийдется честно делать через with recurvise эффективно работать не будет к сожалению.

Самый первый пришедший в голову пример - сортировка элементов массива (сделанная любым честным алгоритмом а не через array(unnest(..) order by).