возьмите приблизительное количество строк из статистики
select
*,
(
select n_live_tup
from pg_stat_user_tables
where relname = 'clients'
/*добавь схему ещё*/
)
from clients
offset 10
limit 10
UPD
Если вы хотите очень приблизительный результат ( допустим, у вас условия по выборке идёт и вы не можете применить выше ) - запустите explain и вытяните кол-во записей из планировщика. ( конечно, если у вас данные нормально распределены )
Ну ещё кэши запросов есть на всякий ( внешний кэш имею в виду )
+ по хорошему - надо бы делать все тесты на именно на холодном кэше, ну или грязном. А судя по второму плану - там явно всё уже было в кэше.
+ интересно, что статистика по таблице поменялась :) :)
+ сравнение поиска без индекса и с индексом - ну это такое себе. Лучше уж сравнивать тот-же b-tree и hash. Ну и сразу показать разницу между поиском по уникальным значениям и когда значения часто повторяются
+ мб я уже сильно далеко захожу. Но можно было вкратце объяснить, как работает именно поиск + что делает hash_mem_multiplier при этом
А вообще, хотелось бы кое-что добавить сюда:
Хэш-индекс не умеет в `index only scan` , поскольку он всегда проверяет строку в в таблице. У b-tree такой проблемы нет из-за карты видимости
Он меньше весит, чем b-tree, но строится в 1 поток ( btree умеет в многопоточку). ЗЫ это инфа старая, мб сейчас умеет, точно не знаю
Хэш-фукнция работает только с операциями равенства ( т.е. column = value ), другие операции ему не доступны. B-tree умеет в поиск по интервалам, поскольку у него всё отсортировано
Не умеет в UNIQUE
Не умеет в INCLUDE
И самое главное - hash-индекс очень помогает, когда вы его правильно употребляете. Ради примера: соединение больших наборов строк по нескольким столбцам сразу. Вы можете увидеть, что планировщик и так решает делать hashJoin, вот вы можете прекрасно базе помочь - просто сделайте по большой таблице хэш-индекс сразу по столбцам, которые участвуют в присоединении
P. S. Особенно вредно и абсолютно непродуктивно менять параметры СУБД во время аварийной ситуации(что как раз и очень любят настойчиво требовать разнообразные манагеры).
А разработчики ?))
увидел в аналайзе, что при большом запросе оч много чтения происходит ( не лежало в shared_buffers ) и сразу давай увеличивать буфер )
Или выполнялась долго группировка - ай-да увеличим воркмем до 2Гб ( и 200 коннектов оставим ) :)
Ну ещё из крижа - медленно записывается в БД - отключи wal и fsync
Пока-что для проверки можно взять функционал из раздела генерации "добивочных" миграций, а именно ( первые 2 пункта взяты): 1) Возьмём клон dev-базы 2) Накатим туда весь МР 3.1) Меньше рисков: сравним с фич-БД, путём сравнивания именно генерации файлов ( обработанный выхлоп pg_dump) 3.2) Альтернативный вариант, но больше рисков: сравнение сделать не через структуру файлов, а через диф-утилиту
Конечно, надо понимать, что ни первый, ни второй вариант не спасут от ошибки, если в результате МР мы создаём уникальный индекс по уже существующему полю, а там есть дубли. Тут могут вызникнуть некоторые проблемы, которые будут зависеть от того, каким инструментом заливки пользоваться
Ну генерировать скрипты на удаление и создание. Как вариант с другой стороны - не допускать такой архитектуры в системе ( ну или как-то абстрагировать структуры )
то есть, я явно выразил намерение заменить функцию
Ну так функция уйдёт под замену, если выполняется 3 условия:
Совпадает название
Совпадают типы входных параметров
Совпадают типы выходных параметров
В остальных случаях будет создание новой функции
Причём сохранить DDL надо всех объектов рекурсивно, так как это представление может использоваться в другом представлении, а то — в следующем. Это решаемая задача, но огромный геморрой.
Ну так а для чего предлагается хранение в гите ? Как раз для того, чтобы вы точно видели, что у вас меняется в структуре
в любом случае, если во время разработки вы дропните что-то - система всё равно делает дамп и показывает на файлах, что случилось ( т.е. в гите в МР вы увидите, что у вас удалилось в итоге )
Мы пока ещё не дошли до теста удаления вью и 100% не могу сказать, на сколько система сможет полностью восстановиться ( пересоздать вьюшки )
ЗЫ добавлю, что мы не так часто используем вью. Например, если клиент не гибкий ( например даталенз ).
не не, всё дело в том, что VIEW у PG хранится уже как скомпиленная ( разобран SQL-запрос в свой формат ). Т.е. если иначе представить - ПГ во вьюхе стучится не по названию и входных параметрам, а по oid функции ( удалили функцию, потеряли oid )
CREATE OR REPLACE FUNCTION или CREATE OR REPLACE PROCEDURE. А как еще?
Это понятно, что такие скрипты. Как вы эти скрипты на прод зальёте ? Руками или через какой-то софт ? ( я намекаю, что софт кушает как раз миграции ( файлы со скриптами) для БД )
В ветке контура не только интеграционное и нагрузочное, но даже просто полноценное тестирование произвести в общем случае невозможно. Для контуров БД обрезается многократно до скромных не более чем сотни гигабайт.
Никто вам не мешает использовать,, условно ZFS и быстро откатываться назад
А замораживать на несколько дней тестирования релиза основную ветку разработки - не лучшая идея. Особенно, если релизный цикл всего 1-2 недели.
Вводите промежуточный сервер Я не понимаю, при чём тут рассмотрение стейджей ревью, тестирования и т.д. к теме этой статьи ( я напомню, что статья про хранение скриптов для версионирования БД )
И Вы так и не ответили на вопрос об отказе от препроцессинга.
Мб я тупой, но не могли бы вы по другому поставить вопрос ?
https://www.postgrespro.ru/education/courses
Ну как минимум вот эти курсы довольно хороши
Из книг - ну если нужно что-то на русском языке - опять же от этих ребят есть 2 книги по постгресу. Одна у Рогова, вторая у Моргунова
Что, зачем это делать, как это поможет и при каких условиях ?
А это что такое, почему не generate_seriaes ? ( тот же вопрос и про удаление ( коммент был выше, да и вообще, почему не транкейт ? )
Раз уж массовая производительная обработка, то почему нет `merge` ?
Просто вброс какой-то инфы, взятой из разных источников, вообще не информативно ничего.
Давайте я вам предложу способ получше:
возьмите приблизительное количество строк из статистики
UPD
Если вы хотите очень приблизительный результат ( допустим, у вас условия по выборке идёт и вы не можете применить выше ) - запустите explain и вытяните кол-во записей из планировщика. ( конечно, если у вас данные нормально распределены )
Ну ещё кэши запросов есть на всякий ( внешний кэш имею в виду )
Скорее это оптимизация работы кластера
Индексы - оптимизация чтения ( выполнения запросов)
А вот оптимизация запросов - это правильно писать сами запросы
Что-то явно напутали :)
+ по хорошему - надо бы делать все тесты на именно на холодном кэше, ну или грязном. А судя по второму плану - там явно всё уже было в кэше.
+ интересно, что статистика по таблице поменялась :) :)
+ сравнение поиска без индекса и с индексом - ну это такое себе. Лучше уж сравнивать тот-же b-tree и hash. Ну и сразу показать разницу между поиском по уникальным значениям и когда значения часто повторяются
+ мб я уже сильно далеко захожу. Но можно было вкратце объяснить, как работает именно поиск + что делает
hash_mem_multiplierпри этомА вообще, хотелось бы кое-что добавить сюда:
Хэш-индекс не умеет в `index only scan` , поскольку он всегда проверяет строку в в таблице. У b-tree такой проблемы нет из-за карты видимости
Он меньше весит, чем b-tree, но строится в 1 поток ( btree умеет в многопоточку). ЗЫ это инфа старая, мб сейчас умеет, точно не знаю
Хэш-фукнция работает только с операциями равенства ( т.е. column = value ), другие операции ему не доступны. B-tree умеет в поиск по интервалам, поскольку у него всё отсортировано
Не умеет в UNIQUE
Не умеет в INCLUDE
И самое главное - hash-индекс очень помогает, когда вы его правильно употребляете. Ради примера: соединение больших наборов строк по нескольким столбцам сразу. Вы можете увидеть, что планировщик и так решает делать hashJoin, вот вы можете прекрасно базе помочь - просто сделайте по большой таблице хэш-индекс сразу по столбцам, которые участвуют в присоединении
Добавь ещё:
Откуда я знаю, что запрос тормозит, я его через орм генерировал)
А разработчики ?))
увидел в аналайзе, что при большом запросе оч много чтения происходит ( не лежало в shared_buffers ) и сразу давай увеличивать буфер )
Или выполнялась долго группировка - ай-да увеличим воркмем до 2Гб ( и 200 коннектов оставим ) :)
Ну ещё из крижа - медленно записывается в БД - отключи wal и fsync
Пока-что для проверки можно взять функционал из раздела генерации "добивочных" миграций, а именно ( первые 2 пункта взяты):
1) Возьмём клон dev-базы
2) Накатим туда весь МР
3.1) Меньше рисков: сравним с фич-БД, путём сравнивания именно генерации файлов ( обработанный выхлоп pg_dump)
3.2) Альтернативный вариант, но больше рисков: сравнение сделать не через структуру файлов, а через диф-утилиту
Конечно, надо понимать, что ни первый, ни второй вариант не спасут от ошибки, если в результате МР мы создаём уникальный индекс по уже существующему полю, а там есть дубли.
Тут могут вызникнуть некоторые проблемы, которые будут зависеть от того, каким инструментом заливки пользоваться
Уточните, пожалуйста, вы имеете в виду проверку именно правильности выполнения миграций или вообще проверки кода, не связанные с тематикой статьи ?
Ну генерировать скрипты на удаление и создание.
Как вариант с другой стороны - не допускать такой архитектуры в системе ( ну или как-то абстрагировать структуры )
Ну так функция уйдёт под замену, если выполняется 3 условия:
Совпадает название
Совпадают типы входных параметров
Совпадают типы выходных параметров
В остальных случаях будет создание новой функции
Ну так а для чего предлагается хранение в гите ?
Как раз для того, чтобы вы точно видели, что у вас меняется в структуре
в любом случае, если во время разработки вы дропните что-то - система всё равно делает дамп и показывает на файлах, что случилось ( т.е. в гите в МР вы увидите, что у вас удалилось в итоге )
Мы пока ещё не дошли до теста удаления вью и 100% не могу сказать, на сколько система сможет полностью восстановиться ( пересоздать вьюшки )
ЗЫ добавлю, что мы не так часто используем вью. Например, если клиент не гибкий ( например даталенз ).
Я могу сейчас ошибаться.
Но функции на plpgsql у вас кэшируются при первом выполнении ( строится план и кэшируется в локальной памяти процесса )
Так вот, как мне кажется, если удалили функцию после кэширования и создали новую - можно получить ошибку ( хотя я такого не встречал, если честно )
не не, всё дело в том, что VIEW у PG хранится уже как скомпиленная ( разобран SQL-запрос в свой формат ).
Т.е. если иначе представить - ПГ во вьюхе стучится не по названию и входных параметрам, а по oid функции ( удалили функцию, потеряли oid )
Представления зависят, при дропе надо будет пересоздавать вьюхи
100, 101 и 102
Это как раз пример того, как собирают код в миграции ( это всё разные файлы версии БД )
Поэтому они даже гит-конфликтом не отловятся
Это понятно, что такие скрипты. Как вы эти скрипты на прод зальёте ?
Руками или через какой-то софт ? ( я намекаю, что софт кушает как раз миграции ( файлы со скриптами) для БД )
Никто вам не мешает использовать,, условно ZFS и быстро откатываться назад
Вводите промежуточный сервер
Я не понимаю, при чём тут рассмотрение стейджей ревью, тестирования и т.д. к теме этой статьи ( я напомню, что статья про хранение скриптов для версионирования БД )
Мб я тупой, но не могли бы вы по другому поставить вопрос ?
Немного не понял, а как вы предлагаете заливать функции и процедуры в прод ?
ЗЫ думаю, вы не верно интерпретировали слово "миграция" в контексте этой статьи
Вы можете выполнять тесты как в общей ветке разработки, как в предпроде, так и в фич-ветке и соответствующей ей БД, вас никто не ограничивает
так вопрос не в том, чтобы иметь разные БД, а в том, как хранить и делать ревью
Ну потому что это разные файлы