|
|
|
MATERIALIZED VIEW
|
|||
|---|---|---|---|
|
#18+
Не нашел подробностей, поэтому может кто подскажет. Есть внешний источник данных, через *fdw создаю foreign таблицы, и из них делаю MATERIALIZED VIEW. Здесь вопросов нет? все понятно. Мне не понятно, что происходит при REFRESH MATERIALIZED VIEW? Т.е., например, в таблице из 1кк записей изменится только 1 запись,а остальные буду те же или если измененных записей будет 1k/10k. Затраты будут одинаковы, т.е. тупо очищаются и перезаписываются результатом запроса или какая то магия присутствует? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2019, 20:01 |
|
||
|
MATERIALIZED VIEW
|
|||
|---|---|---|---|
|
#18+
Troglodit, https://github.com/postgres/postgres/blob/REL_11_STABLE/src/backend/commands/matview.c#L314 - создаётся новая табличка. temporary для concurrently refresh - заполняется методом выполнения запроса через обычную машинерию выполнения запроса, но с сохранением результата в эту табличку. Да, пересчитывается весь matview целиком. - не concurrently обновление - подменяет файл таблички на новый - concurrently обновление делает обычные insert/update/delete (см. refresh_by_match_merge, именно запросы и строятся) только различающихся данных По итогу: Любой refresh выполняет запрос матвьюхи полностью. В wal пишется только различие данных для concurrently обновления, либо вся полученная таблица с заново построенными индексами для не-concurrently ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2019, 21:19 |
|
||
|
MATERIALIZED VIEW
|
|||
|---|---|---|---|
|
#18+
Melkij,спасибо за ответ. Т.е. я правильно понимаю, что если для заполнения view запрос тяжелый, то до момента исполнения запроса и "подменяет файл таблички на новый" все равно можно будет пользоваться устаревшими данными? Я просто помню в 9.* вроде бы была блокировка эклюзивная или путаю? Хотя может к pg12 все и поменялось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2019, 21:52 |
|
||
|
MATERIALIZED VIEW
|
|||
|---|---|---|---|
|
#18+
Troglodit, при concurrently - будут доступны старые данные. Без concurrently - эксклюзивная блокировка и все желающие любым образом прикоснуться к обновляемой матвьюхе - ждут завершение refresh. Равно применимо для всех версий postgresql, кроме 9.3 где refresh уже был, но CONCURRENTLY опции для него ещё не было. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2019, 21:59 |
|
||
|
MATERIALIZED VIEW
|
|||
|---|---|---|---|
|
#18+
Melkij,спасибо. Вы как всегда правы. concurrently это мой вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2019, 22:13 |
|
||
|
MATERIALIZED VIEW
|
|||
|---|---|---|---|
|
#18+
Troglodit Melkij,спасибо. Вы как всегда правы. concurrently это мой вариант. Стоит учитывать что если при refresh меняется не 0.1-5% строк а все 100% сток или около того то при CONCURRENTLY 1)будет сильно дольше и тяжелее (легко в 5 раз может быть) 2)будут сильно индексы на матview имеющиеся пухнуть... для ситуации когда меняется почти все содержимое matview при refresh скорее всего самый эффективный вариант будет сделать новый matview и потом в транзакции удалить старый и переименовать старый в новый. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2019, 23:17 |
|
||
|
MATERIALIZED VIEW
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, спасибо за уточнение. Про пункт 1,2 я догадывался. Буду мелкие слабообновляемые статичные view делать CONCURRENTLY, c тяжелыми посмотрю, что можно сделать. Может не совсем по теме вопрос, а если попробовать использовать PipelineDB, у меня все равно дальше были планы его попробовать использовать для дашбордов и агрегации? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2019, 23:45 |
|
||
|
|
start [/forum/topic.php?fid=53&msg=39885450&tid=1994960]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
48ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
| others: | 15ms |
| total: | 155ms |
| 0 / 0 |
