LINUX.ORG.RU

Сложный вопрос про реплики в 9.1, которая сделана средствами самой postgres

 ,


0

2

Есть 2 машины. На одной крутиться база (большая база, с редкими изменениями данных (раз в 10 минут), но большими изменениями - одна транзакция может менять миллионный строк, или вставлять миллионы).

Есть реплика всего этого.

На всем этом сверху должен работать некоторый sql, достаточно большой. В нем используется CREATE TEMP TABLE, CREATE INDEX и тд. Без этого обойтись нельзя, при попытки использовать with (фактически подзапросами) посгря сходит с ума от многостраничного sql и делает такой план запроса, дождаться выполнение которого невозможно (а с create table это выполняется за разумные несколько минут).

Так вот, на реплике это сделать не получается, так как нельзя создать временные таблицы.

И вот сам вопрос: какие обходные пути можно применить в этом случае? VIEW, WITH не годятся. Реплика на тригерах превратит процесс изменения базы в неподъемную задачу, и так транзакции занимают по получасу иногда.

★★★★

1) Можно хинтами понастроить запрос 2) Можно около реплики поднять еще один postgresql, и из него делать запросы к реплике посредством dblink (http://www.postgresql.org/docs/current/static/dblink.html). Так как это будет отдельный постгрес, то в нем можно создавать временные таблицы.

dmitry_vk ★★★
()
Ответ на: комментарий от namezys

Второй интересней, я о нем думал, но боюсь, что будет медленно

Зависит от количества данных во временной таблице (которые надо будет переслать во второй постгрес).

Первый пункт не понял

В постгресе есть способы повлиять на план запроса. Возможно, что достаточно будет собрать статистику по БД (http://www.postgresql.org/docs/9.1/static/sql-analyze.html), чтобы постгрес использовал правильный план; или поменять параметры планировщика запросов (http://www.postgresql.org/docs/9.2/static/runtime-config-query.html).

dmitry_vk ★★★
()
Ответ на: комментарий от dmitry_vk

Ну иногда временная таблица содержит по несколько млн строк.

Влиять не план запроса бесполезно, когда там подзапросов из 10 уровней вложенности. И еще почти на каждой уровень агрегация.

namezys ★★★★
() автор топика
Ответ на: комментарий от dmitry_vk

опа, постгря уже умеет хинты? Они раньше клялись и божились что никогда не сделают этого. Типа если скорость хромает то открывайте багрепорт, а не запросы подкручивайте.

true_admin ★★★★★
()
Ответ на: комментарий от dmitry_vk

нас только это не спасает. Вполне закономерная ситуация.

Есть 2 таблица c, a и еще много дополнительный (маленький, не более 100 000 строк).

Создаются 2 временные _a, _c - каждая есть выбор из a и с c агрегацией и join на другие таблицы, но туда уже выбирается только часть исходных таблиц.

Потом делается над _a еще с 10 разных агрегаций _a1, _a2, _a3 и тд. Все пишется по временные таблицы. Иногда удобно агрегировать одни временные на другие.

А потом приходится писать SELECT *, (SELECT smth FROM _a WHERE ...), (SELECT smth FROM _a1 WHERE ...), ... FROM c; и так далее.

Если все это запихнуть в один запрос, он в жизнь не догадается делать так.

А иногда в связи с большим объемом _a (которая конечно партицирована) приходится строить _1_a, _2_a и так далее на основе каждой из партиции, а потом сливать. Происходит это потому, что если выбирать из _a постгря сразу считает, что памяти на групповые операции у нее не хватит, и начинает использовать merge на диске, а не hash в памяти. А если по отдельности - то на каждую таблицу хватает памяти.

Ну и много еще всякого секса.

ЗЫ: _c имеет сейчас примерно 400 000 000 записей с примерно 18 столбцами, 4 из которых массивы _a имеет где-то 1 500 000 000 записей с примерно 12 столбцами, 2 из них массивы

namezys ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.