так может обработали ошибку сами и передоподключаются

я так понял)

ну так обмажся похапе покажи код

перескок на другой сервер это комплексная задачка

либо ее pgpool решает либо pgbouncer

либо клиент :)

но обычно плохо

если руками в коде - код должен ловить

в доке описана функция pg_connect, я так понимаю?

если нет этого кода....

недавно наткнулся, что aiopg криво обрабатывает таймауты и ивентлуп блокирует: https://github.com/aio-libs/aiopg/issues/375

Между приложением и слейвом нет пгбаунсера и иже с ними

Все напрямую

ну так как ты ловишь смерть коннекта?

в доке описана функция pg_connect, я так понимаю?

это синтаксис connection string, можно везде пихать его (если это поверх libpq)

ну так как ты ловишь смерть коннекта?

+1 так будет понятнее о чем вопрос

код на php

а ты ловишь смерть коннекта при любом обращении к бд?

или только на коннект?

вот делаешь ты селект. ебнулась база. драйфер pg выдаст соответсвтующий код ошибки. ты это ловишь?

обертка над пдо есть для fallback?

тоже при любых действиях с бд. этот слой кода написан?

а ты ловишь смерть коннекта при любом обращении к бд?

при каждом запросе

Код надо видеть.

Как выполнить команду insert into my_schema.my_table ... выходит ошибка schema "schema" does not exist

Как выполнить команду insert into my_schema.my_table ... выходит ошибка schema "schema" does not exist

А откуда взялась схема "schema", если вы вставляли в "my_schema.my_table"?

Вот такая ошибка прилетает

А в запросе вообще слово schema фигурирует?

А триггеров нет?

нет

1 минуту проверю еще один ариант

да, на нижнее подчеркивание реагирует неадекватно

переименовал схему в myschema всё норм

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

CREATE SCHEMA my_example; -- meta tables for schema and table name CREATE TABLE my_example.schma(schma_id int, schma text); INSERT INTO my_example.schma VALUES (1, 'x'); не понимаю. Этот, вариант например работает. буду думать что в логике бэкенда где-то ошибка что запрос как-то не так воспринимается

Выяснил. Оказалась ошибка в PK. Там serial поле. И при периемновании схемы не переименовался дефолт

nextval('myschema.main_id_seq'::text::regclass) так и осталась.

Самый большой канал, где бесплатно сливают платный качественный контент и курсы. Подписаться — https://t.me/joinchat/AAAAAEAsb3J_7HFOYPZfwA

Всем привет, может быть кто что посоветует. Ситуация такая. Каждый день в таблицу добавляется 200 тысяч записей, данные о продуктах, имеют различные параметры, в том числе цену и дату добавления. Я хочу знать среднюю цену за каждый день с учетом каких-либо параметров. Примерный запрос SELECT date, AVG(price) FROM products WHERE someparam > 5 GROUP BY date ORDER BY date ASC Я хочу хранить данные за период полгода, а это 30*6*200 000 = 36 миллионов записей. В ввиду такого количества запрос выполняется довольно долго. Есть ли какие-то способы ускорить этот запрос? Может вообще стоит вместо postgresql выбрать что-то другое? Любым советам и критике буду рад.

OLAP какой-нибудь типа кликхауса или хранить результаты агрегации по кускам. закончился день - положили среднюю цену в отдельную табличку. потом удобно считаем по 180 строчкам всего

или столбцовое хранилище, забыл как называется, cstore_fdw вроде

зависит от того, какие еще запросы будут

Запрос только средняя цена за день с определенными параметрами

Параметры - 2 целочисленных и 5-7 булевых

1 Geometry

OLAP какой-нибудь типа кликхауса или хранить результаты агрегации по кускам. закончился день - положили среднюю цену в отдельную табличку. потом удобно считаем по 180 строчкам всего

Насчет хранения агрегации по-моему не получится, т.к. мне нужно среднее значение с учетом различных параметров.

а стандартный совет шардировать большую таблицу по дням? будете считать среднее на таблице в 200к за день

а стандартный совет шардировать большую таблицу по дням? будете считать среднее на таблице в 200к за день

Я так понял шардировать - это хранить данные за каждый день в отдельной таблице? Это у меня получится 180 таблиц и если мне нужны данные за полгода - это надо выполнить 180 запросов? Правильно? Вообще это даст какой-то выигрыш в скорости? По-моему всё также нужно пройти все 36 миллиннов записей.

Я так понял шардировать - это хранить данные за каждый день в отдельной таблице? Это у меня получится 180 таблиц и если мне нужны данные за полгода - это надо выполнить 180 запросов? Правильно? Вообще это даст какой-то выигрыш в скорости? По-моему всё также нужно пройти все 36 миллиннов записей.

Шардировать - это разносить таблицы по разным серверам... Разбивать таблицу на части - это партиционирование/секционирование

Всем привет, может быть кто что посоветует. Ситуация такая. Каждый день в таблицу добавляется 200 тысяч записей, данные о продуктах, имеют различные параметры, в том числе цену и дату добавления. Я хочу знать среднюю цену за каждый день с учетом каких-либо параметров. Примерный запрос SELECT date, AVG(price) FROM products WHERE someparam > 5 GROUP BY date ORDER BY date ASC Я хочу хранить данные за период полгода, а это 30*6*200 000 = 36 миллионов записей. В ввиду такого количества запрос выполняется довольно долго. Есть ли какие-то способы ускорить этот запрос? Может вообще стоит вместо postgresql выбрать что-то другое? Любым советам и критике буду рад.

Довольно долго - это сколько?

ну кстати даже от партицирования выигрыш будет, если один запрос одно ядро жрет

Довольно долго - это сколько?

Если запрос без параметров, то минуту и больше

SELECT date, AVG(price) FROM products WHERE someparam > 5 GROUP BY date ORDER BY date ASC В вашем случае явная зависимость от даты. Думаю секционирование по дате должно помочь - так как на каждой секции будет свой маленький индекс... и при группировке будет просматриваться 1 секция за каждый день...

Так же плюсом будет ускоренная вставка...

и еще можно секции разнести по разным дискам. Это здорово ускорит подъем данных в память.

Спасибо за советы. Пока мне кажется вариант с OLAP проще. Типа поставил, внес данные и всё быстро работает. Или не всё так просто с ним?

Спасибо за советы. Пока мне кажется вариант с OLAP проще. Типа поставил, внес данные и всё быстро работает. Или не всё так просто с ним?

Так, OLAP то это всего лишь архитектура БД. Тот же кликхаус просто заточен под OLAP нагрузку, если вы будете использовать просто OLAP движок поверх postgres (mondrian например), проблема сама не уйдет

Так, OLAP то это всего лишь архитектура БД. Тот же кликхаус просто заточен под OLAP нагрузку, если вы будете использовать просто OLAP движок поверх postgres (mondrian например), проблема сама не уйдет

А если я возьму и установлю параллельно постгресу кликхаус, перенесу в него все данные и буду делать запросы?

В кх нативное парционирование по датам. Так что вашу проблему он решит

А если я возьму и установлю параллельно постгресу кликхаус, перенесу в него все данные и буду делать запросы?

Не уверен, что будет быстрее - я на практике кликхаус не использовал. У нас http://community.pentaho.com/projects/mondrian/ поверх pg

Но он append only, без апдейтов, поэтому решайте сами, сможете ли так жить

Апдейты не нужны

Пентахо первоначальную таблицу не изменяет, если я не ошибаюсь

Но строит над ней материализованные вьюхи

Поправьте, если не прав

пентахо будет медленней

Но строит над ней материализованные вьюхи

Там есть варианты - обычно от секционирует опять же.

там же ROLAP внутрях же, что не добавляет ему скорости

Это правда, что pgsql умеет в репликацию мастер-мастер, а мускуль - нет?

Мускуль для аутистов не осиливших посгрю.

никто из них не умеет и, скорее всего, и не будет

никто из них не умеет и, скорее всего, и не будет

Ээ. А в чём проблема?

если вы работаете с sql и вам нужен acid, то мастер-мастер вам на самом деле не нужен

в невозможности атомарной синхронизации распределенной системы?

у mysql galera есть, если сильно master-master нужен

Благодарю!

Мускуль для аутистов не осиливших посгрю.

мыскль для несчастных, ошибочно считающих, что он проще постгреса.

Вроде бы первоначальная настройка мускуля проще. Но всегда можно взять образ с докерхаб. Там он с хорошим скриптом идёт.

чем проще-то? одно и тоже

Первоначальная настройка мыскля годится только под БД для интернет-странички о том, какой у мамы замечательный ребёнок - владелец этой странички. Чуть больше - начинается кино. Бесплатный цЫрк, ну и вот это фсйо.

чем проще-то? одно и тоже

Пятница - завтра.

Пятница - завтра.

причем тут это?

Не нужно трогать никакой pg_hba.conf.