POWER в PostgreSQL: степени, корни и формулы роста в SQL

POWER(base, exponent) возводит число в степень. Например, POWER(2, 10) возвращает 1024, потому что 2 в десятой степени — это 1024.

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

Проще говоря, POWER пригодится в тот момент, когда обычного сложения, вычитания и умножения уже не хватает.

Базовый синтаксис POWER

Функция принимает два аргумента:

POWER(base, exponent)

base — основание степени.

exponent — показатель степени.

Например:

SELECT POWER(2, 10) AS result;

Результат:

result
------
1024

Читается это так: «возвести 2 в степень 10».

Ещё несколько простых примеров:

SELECT
    POWER(10, 3) AS thousand,
    POWER(10, 6) AS million,
    POWER(2, 8) AS byte_values;

Результат:

thousand | million | byte_values
---------+---------+------------
1000     | 1000000 | 256

В аналитике такие выражения встречаются чаще, чем кажется. Например, POWER(10, 6) удобно читать как «миллион», а POWER(2, 10) часто всплывает в задачах про размеры данных.

Показатель может быть нулевым или отрицательным

Если показатель степени равен 0, результат будет 1.

SELECT POWER(7, 0) AS result;

Результат:

result
------
1

Это обычное математическое правило: любое ненулевое число в нулевой степени равно 1.

Отрицательный показатель даёт дробь.

SELECT POWER(2, -1) AS result;

Результат:

result
------
0.5

Почему так?

2 в степени -1 — это то же самое, что 1 / 2.

Ещё пример:

SELECT POWER(10, -2) AS result;

Результат:

result
------
0.01

10 в степени -2 — это 1 / 100.

Оператор степени в PostgreSQL

В PostgreSQL есть не только функция POWER, но и оператор ^.

SELECT 2 ^ 10 AS result;

Результат:

result
------
1024

Такую запись часто удобнее читать в формулах: она короче и похожа на математическую запись.

Но здесь есть важное предупреждение. Не во всех базах данных ^ означает степень.

В PostgreSQL:

SELECT 2 ^ 10 AS result;

это возведение в степень.

А вот в MySQL и ClickHouse символ ^ обычно означает побитовое XOR, а не степень. Поэтому при переносе запросов между СУБД безопаснее использовать функцию POWER или POW.

Например:

SELECT POWER(2, 10) AS result;

Такой вариант понятнее и переносится спокойнее.

POW и POWER

В PostgreSQL можно использовать POWER. Также встречается короткое имя POW.

SELECT POW(2, 10) AS result;

Результат будет тем же:

result
------
1024

Но для учебных запросов лучше писать POWER. Название длиннее, зато сразу понятно, что происходит: число возводится в степень.

POW чаще встречается в MySQL, ClickHouse и в языках программирования. Если вы читаете чужой SQL и видите POW, воспринимайте его как короткую форму POWER.

Тип результата

В PostgreSQL результат зависит от типов аргументов.

Если вы работаете с обычными числами, результат часто будет вещественным, то есть числом с дробной частью. Например:

SELECT POWER(2, -1) AS result;

Результат:

result
------
0.5

Это логично: отрицательные и дробные степени легко дают дробный результат.

Если вам нужно получить целое число, можно округлить результат:

SELECT ROUND(POWER(2, 10))::bigint AS result;

Результат:

result
------
1024

Но не стоит бездумно округлять всё подряд. Для финансов, процентов и аналитики дробная часть часто как раз важна.

Дробные показатели и корни

Самая красивая часть POWER — дробные степени.

Корень можно записать как степень с дробным показателем.

Квадратный корень из числа — это степень 1/2.

Кубический корень — степень 1/3.

Корень четвёртой степени — степень 1/4.

Например:

SELECT POWER(27, 1.0 / 3) AS cube_root;

Результат:

cube_root
---------
3

Почему?

Потому что 3 * 3 * 3 = 27.

Значит, кубический корень из 27 равен 3.

Ещё пример:

SELECT POWER(16, 0.25) AS fourth_root;

Результат:

fourth_root
-----------
2

Потому что 2 * 2 * 2 * 2 = 16.

Для квадратного корня в PostgreSQL есть отдельная функция SQRT:

SELECT SQRT(2) AS result;

Но SQRT умеет только квадратный корень, а POWER позволяет выразить корень любой степени.

SELECT
    POWER(16, 1.0 / 2) AS square_root,
    POWER(27, 1.0 / 3) AS cube_root,
    POWER(81, 1.0 / 4) AS fourth_root;

Почему важно писать 1.0 / 3, а не 1 / 3

Это очень частая ловушка для новичков.

В PostgreSQL выражение:

SELECT 1 / 3 AS result;

даёт:

result
------
0

Почему? Потому что оба числа целые. PostgreSQL выполняет целочисленное деление и отбрасывает дробную часть.

А теперь представьте, что вы пишете кубический корень так:

SELECT POWER(27, 1 / 3) AS result;

Вы ожидаете 3, но фактически показатель степени станет 0.

Получится:

SELECT POWER(27, 0) AS result;

А любое число в нулевой степени — это 1.

Правильная запись:

SELECT POWER(27, 1.0 / 3) AS result;

Результат:

result
------
3

Запомните простое правило: для дробных степеней пишите 1.0 / n, а не 1 / n.

Так вы явно показываете базе: «мне нужно дробное деление».

Сглаживание больших значений

В аналитике часто бывают значения с большим разбросом.

Например, большинство заказов на сумму от 500 до 5000, но иногда встречается огромная сделка на 900000. Если построить график по исходным суммам, этот один большой заказ растянет шкалу, а все обычные заказы слипнутся внизу.

В таких случаях значения иногда сглаживают: не заменяют исходную сумму, а строят дополнительную метрику, которая уменьшает влияние выбросов.

Один из вариантов — кубический корень:

SELECT
    id,
    amount,
    ROUND(POWER(amount, 1.0 / 3), 2) AS amount_scaled
FROM orders
WHERE status = 'paid'
ORDER BY amount DESC;

Что здесь происходит:

amount — настоящая сумма заказа.

POWER(amount, 1.0 / 3) — кубический корень из суммы.

ROUND(..., 2) — округление до двух знаков после запятой.

Например, маленькие и средние суммы почти не исчезают, а огромные значения становятся менее «тяжёлыми» для графика.

Это не значит, что мы меняем деньги в базе. Мы просто делаем дополнительную колонку для аналитики или визуализации.

Сложный процент и рост

POWER особенно хорошо смотрится в формулах роста.

Классическая формула сложного роста:

base * (1 + rate) ^ periods

Где:

base — начальное значение;

rate — темп роста за один период;

periods — количество периодов.

Допустим, средний чек растёт на 3% в месяц. Хотим оценить, каким он будет через 12 месяцев.

SELECT
    ROUND(AVG(amount), 2) AS avg_now,
    ROUND(AVG(amount) * POWER(1 + 0.03, 12), 2) AS avg_in_year
FROM orders
WHERE status = 'paid';

Разберём выражение:

POWER(1 + 0.03, 12)

1 + 0.03 — это месячный множитель роста. Если рост 3%, значение становится 1.03.

12 — количество месяцев.

POWER(1.03, 12) показывает, во сколько раз значение вырастет за год при ежемесячном росте на 3%.

Если бы мы просто умножили на 1 + 0.03 * 12, это был бы грубый простой рост. А POWER считает именно сложный рост: каждый следующий месяц растёт уже увеличенное значение.

Пример прогноза выручки

Допустим, у нас есть текущая месячная выручка, и мы хотим прикинуть выручку через полгода при росте 5% в месяц.

SELECT
    current_revenue,
    ROUND(current_revenue * POWER(1 + 0.05, 6), 2) AS revenue_after_6_months
FROM monthly_metrics
WHERE month = DATE '2026-01-01';

Формула читается так:

current_revenue * 1.05 ^ 6

То есть текущую выручку умножаем на шесть месяцев сложного роста по 5%.

Такие расчёты полезны для быстрых прогнозов. Но важно помнить: SQL честно считает формулу, а не предсказывает будущее. Если темп роста выбран с потолка, результат тоже будет условной оценкой.

Как посчитать средний темп роста

Есть и обратная задача: мы знаем начальное и конечное значение и хотим понять средний темп роста за период.

Например, было 1000 пользователей, стало 1800 пользователей за 6 месяцев. Какой средний месячный рост?

Формула:

POWER(last_value / first_value, 1.0 / periods) - 1

В SQL это может выглядеть так:

WITH bounds AS (
    SELECT
        1000.0 AS first_value,
        1800.0 AS last_value,
        6 AS periods
)
SELECT
    ROUND(
        (POWER(last_value / first_value, 1.0 / periods) - 1) * 100,
        2
    ) AS monthly_growth_pct
FROM bounds;

Результат:

monthly_growth_pct
------------------
10.29

Это значит: чтобы вырасти с 1000 до 1800 за 6 периодов, нужно расти примерно на 10.29% за период.

Обратите внимание: здесь используется именно отношение конечного значения к начальному:

last_value / first_value

А не просто общее количество строк.

Это важная разница. Если взять COUNT(*) и извлечь из него корень, вы получите нормализацию объёма, но не настоящий темп роста.

Пример с регистрациями пользователей

Предположим, у нас есть таблица ежедневных метрик:

metric_date | users_count
------------+------------
2026-01-01  | 1000
2026-07-01  | 1800

Хотим посчитать средний месячный рост между двумя датами.

WITH bounds AS (
    SELECT
        MIN(users_count)::numeric AS first_count,
        MAX(users_count)::numeric AS last_count,
        6 AS months_count
    FROM user_metrics
    WHERE metric_date IN (DATE '2026-01-01', DATE '2026-07-01')
)
SELECT
    ROUND(
        (POWER(last_count / first_count, 1.0 / months_count) - 1) * 100,
        2
    ) AS avg_monthly_growth_pct
FROM bounds;

Идея такая:

1. Берём начальное значение.
2. Берём конечное значение.
3. Делим конечное на начальное.
4. Извлекаем корень по числу периодов.
5. Вычитаем 1.
6. Умножаем на 100, чтобы получить проценты.

Это уже ближе к настоящему среднему темпу роста.

Геометрическое среднее

Обычное среднее подходит не всегда.

Например, если мы усредняем темпы роста или множители, часто лучше использовать геометрическое среднее. Оно связано со степенями и корнями.

Для нескольких значений формула такая:

(value1 * value2 * value3 * ... * valueN) ^ (1 / N)

То есть мы перемножаем значения и извлекаем корень степени N.

Но в SQL напрямую перемножать много значений опасно: произведение может стать слишком большим. Поэтому на практике часто используют связку LN и EXP.

Например, геометрическое среднее зарплат по отделам:

SELECT
    dept,
    ROUND(EXP(AVG(LN(salary))), 2) AS geo_mean_salary
FROM employees
WHERE salary > 0
GROUP BY dept;

Почему добавили условие:

WHERE salary > 0

Потому что логарифм можно брать только от положительных чисел.

Формально здесь не используется POWER, но идея та же самая: степени, корни и множители. В сложной аналитике эти функции часто ходят рядом.

Переполнение: степени растут очень быстро

Степени растут не плавно, а резко.

Например:

SELECT POWER(10, 3) AS result;

даёт 1000.

SELECT POWER(10, 6) AS result;

даёт 1000000.

SELECT POWER(10, 12) AS result;

даёт уже 1000000000000.

Каждый шаг показателя снова умножает результат на основание. Поэтому большие степени быстро упираются в пределы числовых типов.

Примерно так:

SELECT POWER(10, 308) AS result;

Это значение находится около верхней границы для double precision.

А вот ещё большее значение может привести к ошибке переполнения:

SELECT POWER(10, 309) AS result;

PostgreSQL может сообщить, что значение вышло за допустимый диапазон.

С одной стороны, это неприятно: запрос упал. С другой — это честнее, чем тихо получить неправильное значение и не заметить.

Отрицательное основание и дробная степень

С отрицательными числами нужно быть внимательнее.

Такой пример нормальный:

SELECT POWER(-2, 3) AS result;

Результат:

result
------
-8

Потому что -2 * -2 * -2 = -8.

Но дробная степень для отрицательного основания может стать проблемой:

SELECT POWER(-8, 0.5) AS result;

Математически это квадратный корень из -8. В обычных вещественных числах такого результата нет: он относится к комплексным числам.

PostgreSQL не будет делать вид, что всё нормально. Такой запрос может закончиться ошибкой.

Поэтому правило простое: если показатель дробный, основание должно быть неотрицательным, если вы работаете в обычной вещественной арифметике.

POWER с деньгами и numeric

Для финансовых расчётов типы особенно важны.

double precision быстрый, но это приближённая арифметика. Она подходит для многих аналитических задач, графиков и прогнозов, но не всегда подходит для точных денежных расчётов.

Для денег часто используют numeric.

Например:

SELECT POWER(1.03::numeric, 12) AS growth_factor;

Такой расчёт может быть точнее, но обычно дороже по производительности.

Не нужно приводить всё к numeric «на всякий случай». Лучше понимать задачу:

если это быстрый аналитический прогноз, часто достаточно обычной вещественной арифметики;

если это расчёт денег, процентов, начислений или отчётных значений, типы нужно выбирать аккуратно.

POWER(0, 0)

Есть особый случай:

SELECT POWER(0, 0) AS result;

В PostgreSQL результат будет:

result
------
1

Это может удивить, потому что в математике выражение 0^0 часто обсуждают отдельно. В SQL-системах для функции степени обычно принято возвращать 1.

Для практических задач это редко становится проблемой, но знать полезно: если в данных одновременно могут появиться основание 0 и показатель 0, результатом будет 1, а не ошибка.

MySQL и ClickHouse

В MySQL для степени можно использовать POWER или POW.

SELECT POW(2, 10) AS result;

Результат:

result
------
1024

Но оператор ^ в MySQL — не степень, а побитовая операция. Поэтому такой код переносить из PostgreSQL нельзя:

SELECT 2 ^ 10 AS result;

В PostgreSQL это степень.

В MySQL это уже другой смысл.

В ClickHouse тоже есть pow.

SELECT pow(2, 10) AS result;

Но важно помнить: ClickHouse часто возвращает результат как Float64. Для больших чисел и точных финансовых расчётов это может давать особенности округления.

Главное правило при переносе: не полагайтесь на символ ^. Для степени пишите POWER или POW и проверяйте тип результата.

Частые ошибки с POWER

Первая ошибка — забыть про целочисленное деление.

SELECT POWER(27, 1 / 3) AS result;

В PostgreSQL это может дать не кубический корень, а 1, потому что 1 / 3 превратится в 0.

Правильно:

SELECT POWER(27, 1.0 / 3) AS result;

Вторая ошибка — использовать ^ в другой СУБД и думать, что это степень.

В PostgreSQL:

SELECT 2 ^ 10 AS result;

это степень.

В MySQL и ClickHouse так лучше не писать, если нужна именно степень.

Третья ошибка — не думать о диапазоне значений.

SELECT POWER(10, 309) AS result;

Большие степени могут переполнить тип.

Четвёртая ошибка — брать дробную степень от отрицательного числа.

SELECT POWER(-8, 1.0 / 3) AS result;

С такими выражениями нужно быть осторожным. Даже если математически вы ожидаете кубический корень, конкретная функция и типы могут работать в вещественной области и не принять отрицательное основание с дробным показателем.

Практические примеры

Посчитать размер в байтах, если известна степень двойки:

SELECT POWER(2, 20) AS bytes_count;

Оценить сумму через год при ежемесячном росте 2%:

SELECT ROUND(100000 * POWER(1 + 0.02, 12), 2) AS value_in_year;

Извлечь кубический корень:

SELECT POWER(125, 1.0 / 3) AS cube_root;

Сгладить суммы заказов для отчёта:

SELECT
    id,
    amount,
    ROUND(POWER(amount, 1.0 / 3), 2) AS amount_scaled
FROM orders
WHERE amount > 0;

Посчитать средний темп роста:

WITH values AS (
    SELECT
        1000.0 AS first_value,
        1500.0 AS last_value,
        12 AS periods
)
SELECT
    ROUND(
        (POWER(last_value / first_value, 1.0 / periods) - 1) * 100,
        2
    ) AS growth_pct
FROM values;

Главное из статьи

POWER(base, exponent) возводит число base в степень exponent.

SELECT POWER(2, 10) AS result;

Результат:

result
------
1024

В PostgreSQL можно также использовать оператор ^, но при переносе в MySQL и ClickHouse будьте осторожны: там этот символ может означать не степень, а побитовую операцию.

Дробные показатели позволяют извлекать корни:

SELECT POWER(27, 1.0 / 3) AS cube_root;

Для корней важно писать 1.0 / n, а не 1 / n, чтобы не получить целочисленное деление.

POWER особенно полезен для сложного процента, прогнозов роста, сглаживания больших значений, нормализации метрик и расчёта средних темпов.

Но у функции есть подводные камни: большие степени могут привести к переполнению, дробная степень от отрицательного основания может вызвать ошибку, а для финансовых расчётов нужно внимательно выбирать типы.

Если держать показатели в разумных пределах и явно работать с типами, POWER становится простым и предсказуемым инструментом для аналитики, отчётов и математических формул прямо внутри SQL.