Comments 10
Выглядит очень приятно
не прошло и 20 лет
(SELECT count(*) FROM source_table) > 100000
Может тут LIMIT на строки вставить? Считать такое можно очень долго.
а еще лучше в этом случае статистику из information_schema использовать. 100% точность тут не надо, зато работает мгновенно
Надеюсь не увижу данный опыт в своих Базах:D
В данном случае лучше пытаться ориентироваться на собранную статистику по таблице, например n_live_tuples из представления pg_stat_all_tables
ON condition — это условие, на основании которого происходит сравнение строк из источника
USINGи целевой таблицы. Если условие удовлетворяется, то есть строки совпадают, то выполняется одно из действий, указанных вWHEN MATCHEDилиWHEN NOT MATCHED.
У внимательного, но не сильно разбирающегося в теме, читателя - немедленно возникает вопрос: "А если условие НЕ удовлетворяется?". Догадаться, что WHEN NOT MATCHED - это и есть вариант, когда условие НЕ удовлетворяется, то есть строки НЕ совпадают, практически невозможно.
Вы бы хотя бы прочитали перевод-описание у ПостгрессПро - там это сделано на порядок качественнее. А ещё лучше - изучили бы то, что там написано... на самом деле MERGE - это один огромный CASE, у которого может быть куча альтернативных веток. И единственное синтаксическое условие - это наличие в начале каждой ветки WHEN [NOT] MATCHED, к которому можно присоединять неограниченное количество дополнительных условий. Плюс некоторые логические условия - например, строгое 1:1 соответствие записей.
В общем, вы как-то не очень ответственно отнеслись к первой половине своей статьи. И я считаю, что её просто необходимо доработать и довести до хотя бы приемлемого уровня.
PS. А кусочек про work_mem я бы вообще выбросил. Ну в крайнем случае вскользь упомянул - н уж точно не выносил бы в заголовок статьи. Потому как в относящейся к этому параметру части статьи совершенно ничего по делу в тексте не сказано. Кроме "попробуйте понемногу увеличивать" - а это ни о чём.
MERGE и её улучшение производительности с помощью work_mem