Красота партиционирования.
Партиционирование делит большую таблицу по горизонтали по колонке ключа партиции: все строки с одним и тем же ключом оказываются в своей отдельной таблице, которую и называют партицией.
Логически это всё ещё та же таблица, но при запросах база понимает, в какую партицию лезть, если ключ партиции указан в where.
Такой подход даёт серьёзный прирост производительности и масштабируемости. Можно держать старые партиции, к которым почти не обращаются, на обычных HDD, а свежие — на быстрых SSD.
На каждую партицию можно вешать свои индексы, и они будут куда компактнее, чем один монолитный индекс на всю таблицу.
И к тому же можно убрать целую партицию одной командой, вместо того чтобы удалять строки вручную.
👉 @SQLPortal
Партиционирование делит большую таблицу по горизонтали по колонке ключа партиции: все строки с одним и тем же ключом оказываются в своей отдельной таблице, которую и называют партицией.
Логически это всё ещё та же таблица, но при запросах база понимает, в какую партицию лезть, если ключ партиции указан в where.
Такой подход даёт серьёзный прирост производительности и масштабируемости. Можно держать старые партиции, к которым почти не обращаются, на обычных HDD, а свежие — на быстрых SSD.
На каждую партицию можно вешать свои индексы, и они будут куда компактнее, чем один монолитный индекс на всю таблицу.
И к тому же можно убрать целую партицию одной командой, вместо того чтобы удалять строки вручную.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9😁3
Новый релиз duckdb получился мощным: завезли поддержку Iceberg для INSERT, UPDATE и DELETE.
duckdb можно встраивать куда угодно, так что его реально запускать прямо внутри Postgres, в Edge Functions, в API-серверах и в прочих местах.
👉 @SQLPortal
duckdb можно встраивать куда угодно, так что его реально запускать прямо внутри Postgres, в Edge Functions, в API-серверах и в прочих местах.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤3🤔2
Топ причин, почему Postgres не использует индекс:
Его просто нет.
WHERE отбирает больше 5–10% строк. В такой ситуации Postgres выбирает последовательное сканирование, потому что накладные расходы на работу с индексом будут выше.
Планировщик работает со старыми статистиками. Такое бывает после массовой вставки, крупных UPDATE/DELETE, долгого отсутствия VACUUM или при недавно созданных индексах.
Таблица слишком маленькая. Последовательное сканирование в таком случае быстрее, чем использование индекса с его оверхедом.
Несовпадение типа индекса или использование функций над колонками, по которым есть индекс. Например LOWER(email).
Так что если планировщик не использует индекс — почти всегда он делает это потому, что так дешевле по стоимости запроса.
Надеюсь, пригодится.
👉 @SQLPortal
Его просто нет.
WHERE отбирает больше 5–10% строк. В такой ситуации Postgres выбирает последовательное сканирование, потому что накладные расходы на работу с индексом будут выше.
Планировщик работает со старыми статистиками. Такое бывает после массовой вставки, крупных UPDATE/DELETE, долгого отсутствия VACUUM или при недавно созданных индексах.
Таблица слишком маленькая. Последовательное сканирование в таком случае быстрее, чем использование индекса с его оверхедом.
Несовпадение типа индекса или использование функций над колонками, по которым есть индекс. Например LOWER(email).
Так что если планировщик не использует индекс — почти всегда он делает это потому, что так дешевле по стоимости запроса.
Надеюсь, пригодится.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5👍2