Про такие планы ничего не слышно. Параметры и возвращаемый результат - это все-таки про функции и процедуры. Не очень понятны причины, почему их не использовать.
Дополню, что inval msgs — это сообщения об инвалидации кеша, чтобы все процессы обновили соответствующие элементы в своих локальных кешах, в данном случае — в кешах системного каталога (catcache).
А DELETE — это, видимо, удаление записи из pg_class.
Рад за Оракл, если им удалось добиться какого-то серьезного прогресса. Семь лет назад, когда я на нем сидел, все это было в сильно зачаточном состоянии. Правда, спрос на DBA не уменьшается, так что, боюсь, не все так гладко.
Но мы тут, вроде, про Постгрес говорили, а в нем такой автоматики в любом случае нет.
Не очень понимаю, что такое "по большому счету", но:
оценка планировщика и статистика — разные вещи (статистика — входная информация для оценки);
статистика никак не учитывает характеристики железа, параметры ОС, расположение данных на дисках и т. п., а учитывает только объем и особенности распределения данных (в смысле мат. статистики);
такие факторы, как соотношение времени случайного и последовательного доступа и т. п., задаются администратором с помощью конфигурационных параметров; сами по себе эти настройки никогда не меняются. Возможно, кажется логичным, чтобы такие вещи отслеживались и учитывались автоматически, но нет: воспроизводимость и стабильность планов дороже. Про автономные/самонастраивающиеся СУБД давно говорят, но пока ни у кого хорошо не получается.
В PostgreSQL cost — это среднее время доступа до случайной страницы в БД, поэтому по количеству костов можно посчитать время.
Но эта величина тоже не стабильная и зависит от многих параметров. Например, если диск долгое время был загружен, средняя стоимость изменится, то есть показатель снова будет необъективным.
Ребяты, стоимость (cost) — это оценка планировщика. Она никак не зависит от нагрузки на сервер, скорости работы дисков и т. п. Для одного и того же запроса стоимость может поменяться только при изменении статистики (ну или изменении настроенных параметров).
И уж конечно по оценке стоимости никак нельзя вычислить время.
Дело в том, что без ORDER BY порядок не гарантируется, даже если версии строк физически расположены именно так, как надо.
В случае последовательного доступа — ключевые слова для гугления: synchronized scans.
В случае индексного доступа — легко можно наступить не на тот индекс (например, построенный в обратном порядке). Ну и кроме того, при индексном доступе ORDER BY не несет никаких дополнительных расходов.
Оказалось, что непросто. В 15-ю версию вкатили патч, который должен быть это исправить, а потом откатили обратно - оказалось, не все учли. Теперь может в 16-й версии поправят, вроде шансы есть.
A high value of work_mem is specified globally (at instance level). Users often underestimate the multiplying effect for such blanket decisions.
А у вас совершенно некорректная отсебятина:
Ограничения глобальной переменной work_mem. Например, если у вас 32Гб RAM и work_mem=1Гб, то больше 32 соединений вы никогда не запустите. Каждое соединение PostgreSQL будет выделять этот размер памяти.
Нехорошо так делать, перевод должен быть переводом.
Только что записанные данные обязательно попадают не только в журнал, но и в основную базу. Только не сразу на диск, а сначала в буферный кеш. Вот из буферного кеша они и читаются.
А вот если сервер упадет, тогда недошедшие до диска данные будут восстановлены из журнала.
Да, вы правильно понимаете, с оговоркой на подраздел «Частые и редкие лексемы» - они могут обрабатываться по-разному.
Но специально для этого случае есть класс операторов jsonb_path_ops, и я только сейчас понял, что ничего про него не написал. Он складывает в индекс не отдельные ключи и значения, а целиком путь от корня JSON до значения.
Правильно, ли я понимаю, что количество версий строк зависит, от интенсивности обновления строки и настроек автовакуума?
Да.
И если это так, то при одной версии строки (вставили строку и после не было обновлений и удаления этой строки) речь о корреляции вообще не должна идти, потому что не с чем коррелировать, т.е. нет версий строк?
Нет. Видимо я запутал вас тем, что написал корреляция версий строк (с порядком в индексе), а не просто корреляция строк. Даже если у каждой строки ровно одна версия, то самих-то строк обычно много.
Вот пусть в таблице хранятся числа, для каждой строки есть только одна (актуальная) версия, и в страницах эти версии расположены так:
0 1 2 3 4 5 6 7 8 9.
Тогда корреляция равна единице, поскольку в индексе эти числа упорядочены точно так же.
А если в страницах что-то такое вперемешку:
3 8 2 6 9 4 1 0 7 5,
то корреляция около нуля.
Все это не важно, если мы читаем по индексу ровно одну строку, но очень важно, если читаем много.
Про такие планы ничего не слышно. Параметры и возвращаемый результат - это все-таки про функции и процедуры. Не очень понятны причины, почему их не использовать.
Да их море. Но почему-то эта странная категория «колоночных баз» кочует из статьи в статью.
Вопрос на засыпку: может ли реляционная СУБД быть колоночной?
(Вполне может, потому что реляционность и детали физического хранения данных никак не связаны.)
Дополню, что inval msgs — это сообщения об инвалидации кеша, чтобы все процессы обновили соответствующие элементы в своих локальных кешах, в данном случае — в кешах системного каталога (catcache).
А DELETE — это, видимо, удаление записи из pg_class.
Рад за Оракл, если им удалось добиться какого-то серьезного прогресса. Семь лет назад, когда я на нем сидел, все это было в сильно зачаточном состоянии. Правда, спрос на DBA не уменьшается, так что, боюсь, не все так гладко.
Но мы тут, вроде, про Постгрес говорили, а в нем такой автоматики в любом случае нет.
Не очень понимаю, что такое "по большому счету", но:
оценка планировщика и статистика — разные вещи (статистика — входная информация для оценки);
статистика никак не учитывает характеристики железа, параметры ОС, расположение данных на дисках и т. п., а учитывает только объем и особенности распределения данных (в смысле мат. статистики);
такие факторы, как соотношение времени случайного и последовательного доступа и т. п., задаются администратором с помощью конфигурационных параметров; сами по себе эти настройки никогда не меняются.
Возможно, кажется логичным, чтобы такие вещи отслеживались и учитывались автоматически, но нет: воспроизводимость и стабильность планов дороже. Про автономные/самонастраивающиеся СУБД давно говорят, но пока ни у кого хорошо не получается.
Ребяты, стоимость (cost) — это оценка планировщика. Она никак не зависит от нагрузки на сервер, скорости работы дисков и т. п. Для одного и того же запроса стоимость может поменяться только при изменении статистики (ну или изменении настроенных параметров).
И уж конечно по оценке стоимости никак нельзя вычислить время.
Дело в том, что без ORDER BY порядок не гарантируется, даже если версии строк физически расположены именно так, как надо.
В случае последовательного доступа — ключевые слова для гугления: synchronized scans.
В случае индексного доступа — легко можно наступить не на тот индекс (например, построенный в обратном порядке). Ну и кроме того, при индексном доступе ORDER BY не несет никаких дополнительных расходов.
Это же азы.
Не писать ORDER BY, когда нужна сортировка — лютая дичь. Нельзя так делать, а тем более советовать делать.
Оказалось, что непросто. В 15-ю версию вкатили патч, который должен быть это исправить, а потом откатили обратно - оказалось, не все учли. Теперь может в 16-й версии поправят, вроде шансы есть.
Почитайте про Adaptive Cursor Sharing. Это появилось в Oracle 11g, то есть 15 лет уже как.
Учитывать фактическое значение параметра? Вообще-то все умеют, и давно. И Постгрес, и Оракл.
В каких-то учат, но без практики эти знания забываются примерно сразу после зачёта.
Рад, что книга понравилась!
В оригинале:
А у вас совершенно некорректная отсебятина:
Нехорошо так делать, перевод должен быть переводом.
Только что записанные данные обязательно попадают не только в журнал, но и в основную базу. Только не сразу на диск, а сначала в буферный кеш. Вот из буферного кеша они и читаются.
А вот если сервер упадет, тогда недошедшие до диска данные будут восстановлены из журнала.
Да, вы правильно понимаете, с оговоркой на подраздел «Частые и редкие лексемы» - они могут обрабатываться по-разному.
Но специально для этого случае есть класс операторов
jsonb_path_ops, и я только сейчас понял, что ничего про него не написал. Он складывает в индекс не отдельные ключи и значения, а целиком путь от корня JSON до значения.Вот место в документации, где про это написано.
Ух, какая раритетная у вас книжка по Постгресу! Свежая версия всегда лежит здесь: postgrespro.ru/education/books/introbook
Всегда приятно, когда работа оказывается нужной!
Серия про индексы уже порядком устарела, но в грядущей книге будет свежая информация.
Да.
Нет. Видимо я запутал вас тем, что написал корреляция версий строк (с порядком в индексе), а не просто корреляция строк. Даже если у каждой строки ровно одна версия, то самих-то строк обычно много.
Вот пусть в таблице хранятся числа, для каждой строки есть только одна (актуальная) версия, и в страницах эти версии расположены так:
0 1 2 3 4 5 6 7 8 9.Тогда корреляция равна единице, поскольку в индексе эти числа упорядочены точно так же.
А если в страницах что-то такое вперемешку:
3 8 2 6 9 4 1 0 7 5,то корреляция около нуля.
Все это не важно, если мы читаем по индексу ровно одну строку, но очень важно, если читаем много.