Здравствуйте.
Столкнулся с такой ситуацией.
Есть секционированная таблица. Данных очень много, года за 3-4. Секционирование классическое, если так можно сказать, разбиение по дням, таймстемп поле должно быть в пределах времени суток с 00:00:00 по 23:59:59.
Ограничение check в секционировании работает.
Делаю EXPLAIN SELECT запроса за двое конкретных суток, выдает что да, действительно, будет в запросе задействовано две секции и именно за эти сутки.

Есть другая подобная секционированная таблица, данных там чуть меньше. Секционирование тоже настроено.

Задача такова. Нужно сделать пользовательскую хранимую функцию,Здравствуйте.
Столкнулся с такой ситуацией.
Есть секционированная таблица. Данных очень много, года за 3-4. Секционирование классическое, если так можно сказать, разбиение по дням, таймстемп поле должно быть в пределах времени суток с 00:00:00 по 23:59:59.
Ограничение check в секционировании работает.
Делаю EXPLAIN SELECT запроса за двое конкретных суток, выдает что да, действительно, будет в запросе задействовано две секции и именно за эти сутки.

Есть другая подобная секционированная таблица, данных там чуть меньше. Секционирование тоже настроено.

Задача такова. Нужно сделать пользовательскую хранимую pgsql функцию, которая выбирает из первой секционированной таблицы данные и кладет их в создаваемую в данной функции таблицу результатов, назову ее часть 1, и из второй таблицы тоже, но в другую создаваемую в этой же функции таблицу результатов, назову - часть 2.

Алгоритмически это все мелочи. Реализация есть, так сказать.

При исполнении извлечения только по части 1, все проходит, как и только по части 2.
Но если делаю и Часть 1, и Часть 2 последовательно в одной pgsql функции, то возникает исключение - нехватка разделяемой памяти, попробуйте увеличить max_locks_per_transaction.

Комп серверный, пока с одним восьмиядерным процессороми и 48 Гб оперативы.
Postgres версии 9.3 настраивал через чей-то вебовский в Интернете pgtune.
Может ошибаюсь, но параметры в конфигурации сейчас таковы ( простите за транслит)
соединений = 100
макслокспертранзакшн = 128
шаредмемори = 12Гб

Заглянул в pg_locks, а там при исполнении, например Части 1, стоят блокировки AccessShareLock на абсолютно всех партициях, даже тех, что и в выборке не участвует, каких и в EXPLAIN SELECT нет. Так и должно быть? отсюда берется превышенный лимит блокировок в рамках одной транзакции? Вычислять конкретные секции не хотелось бы. Как быть?

Сейчас все осложнено еще тем,что идет интенсивная, хотя и сбалансированная по нагрузке на процессор, загрузка данных в эту базу. загрузка происходит в конкретные партиции, так просто реализовано. По той же самой причине, применять костыльвторой раз не хочу. О ее оптимизации я спрошу позже. которая выбирает из первой таблицы данные и кладет их в создаваемую в данной функции таблицу результатов, назову ее часть 1, и из второй таблицы тоже, но в другую создаваемую в этой же функции таблицу результатов, назову часть 2.

Алгоритмически это все мелочи. Реализация есть, так сказать.

При исполнении извлечения только по части 1, все проходит, как и только по части 2.
Но если делаю и Часть 1, и Часть 2 последовательно в одной pgsql функции, то возникает исключение - нехватка разделяемой памяти, попробуйте увеличить max_locks_per_transaction.

Комп серверный, пока с одним восьмиядерным процессороми и 48 Гб оперативы.
Postgres версии 9.3 настраивал через чей-то вебовский в Интернете pgtune.
Может ошибаюсь, но параметры в конфигурации сейчас таковы ( простите за транслит)
соединений = 100
макслокспертранзакшн = 128
шаредмемори = 12Гб

Заглянул в pg_locks, а там при исполнении, например Части 1, стоят блокировки AccessShareLock на абсолютно всех партициях, даже тех, что и в выборке не участвует, каких и в EXPLAIN SELECT нет. Так и должно быть? отсюда берется превышенный лимит блокировок в рамках одной транзакции? Вычислять конкретные секции не хотелось бы. Как быть?

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

Забыл сказать, у секций одной и тоже родительской таблицы id поле берется из одной серии, наследуется.
Запросы в функции исполняются через EXECUTE <шаблон>, так как запрос в виде строки формируется динамически ( имена таблиц результатов формируются динамически).

Нужна ваша помощь, благодарю заранее.

не понял

Спасиб!

но все равно не ясно почему АксесШареЛок нанеучаствующей партиции.

suh,
спасиб, вопрос закрыт.