в debian от постгиса отпилили сотни зависимостей: https://github.com/Oslandia/SFCGAL/issues/136#issuecomment-313008690

в debian от постгиса отпилили сотни зависимостей: https://github.com/Oslandia/SFCGAL/issues/136#issuecomment-313008690

опять нет повода не выпить? ))

прям повод таки серьезный))

а какой самый крутой бинарный key-value storage?

Всем доброго времени суток!

в debian от постгиса отпилили сотни зависимостей: https://github.com/Oslandia/SFCGAL/issues/136#issuecomment-313008690

тоесть дебиан 9 можно постгис без иксов уже использовать?:)

stretch-backports

непонял ето не в стабильной ветке?

или просто нужно подключить бекпортс?

vc_production=# reindex table vcfront.api_calls; ERROR: could not create unique index "api_calls_pkey" DETAIL: Key (id)=(2841984) is duplicated. vc_production=# reindex table vcfront.api_calls; ERROR: could not create unique index "api_calls_pkey" DETAIL: Key (id)=(2841889) is duplicated. vc_production=# reindex table vcfront.api_calls; ERROR: could not create unique index "api_calls_pkey" DETAIL: Key (id)=(2841935) is duplicated. vc_production=# select count(id) from vcfront.api_calls; count —------- 1162531 (1 row)

кто такие проблемы решает? :)

vc_production=# reindex table vcfront.api_calls; ERROR: could not create unique index "api_calls_pkey" DETAIL: Key (id)=(2841984) is duplicated. vc_production=# reindex table vcfront.api_calls; ERROR: could not create unique index "api_calls_pkey" DETAIL: Key (id)=(2841889) is duplicated. vc_production=# reindex table vcfront.api_calls; ERROR: could not create unique index "api_calls_pkey" DETAIL: Key (id)=(2841935) is duplicated. vc_production=# select count(id) from vcfront.api_calls; count —------- 1162531 (1 row)

так id сейчас не PK? и даже не уник?

vc_production=# reindex table vcfront.api_calls; ERROR: could not create unique index "api_calls_pkey" DETAIL: Key (id)=(2841984) is duplicated. vc_production=# reindex table vcfront.api_calls; ERROR: could not create unique index "api_calls_pkey" DETAIL: Key (id)=(2841889) is duplicated. vc_production=# reindex table vcfront.api_calls; ERROR: could not create unique index "api_calls_pkey" DETAIL: Key (id)=(2841935) is duplicated. vc_production=# select count(id) from vcfront.api_calls; count —------- 1162531 (1 row)

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

Поэтому и ругается

Запрос напиши на проверку

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

не походу, а имеются и значения id выводит в ругани

а какой самый крутой бинарный key-value storage?

redis не походит?

Ну я и говорю, напиши запрос на вывод количества каждого айди

пусть напишет*

select count(id) from vcfront.api_calls;

redis не походит?

redis неплох

этот запрос показывает количество записей, но не связан с ключем

select count(id) from vcfront.api_calls;

Не, не так. Ща покажу

select product_id, count(product_id) from products_prices group by product_id having count(product_id) > 1 order by product_id, count(product_id);

Во

Значения полей конечно же свои подставить

Точнее наименования*

select product_id, count(product_id) from products_prices group by product_id having count(product_id) > 1 order by product_id, count(product_id);

на логическом уровне проблем нет :)

это физику разъебало. чексуммы не включены

Аа, понятно. А что за чексуммы, поясни плиз

Не сталкивался с таким

да вот так сделай запрос select id from vcfront.api_calls where id=2841984; сколько покажет записей?

Да с логикой у него все норм оказывается, значения уникальны как я понял, что-то там в недрах сломалось)

это физику разъебало. чексуммы не включены

Физику - это именно физика, или таки ФС?

или вот так можно select count(id) from vcfront.api_calls where id=2841984; или так без разницы

так сколько у тебя выводиться записей

?

Физику - это именно физика, или таки ФС?

Или просто файлы БД?

Да с логикой у него все норм оказывается, значения уникальны как я понял, что-то там в недрах сломалось)

где выхлоп запроса говорящий об уникальности поля по тем занчениям на которые он ругался?

Хз, у него спрашивать надо

)))

redis не походит?

redis - самый плохой k/v storage

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

или вот так можно select count(id) from vcfront.api_calls where id=2841984; или так без разницы

Одна строка, так как поиск происходит по индексу, а он не разебан

Даж хз, может materialized view поможет?

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

materialized view

materialized view

нет времени на рефреш перед запросом

Рефрешить один раз в сутки?

там вся таблица за сутки

:)

Вот даже самому интересно, может DBA че подскажут

Вангую там что-то с tablespaces

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

а партицировать по часам не поможет?

а партицировать по часам не поможет?

мы будем проходить больше таблиц, чтобы добыть из них так же размазанные данные :)

сорри :(

нужно достать данных за пару часов, это ~тысяча ивентов, размытых среди миллионов чужих

Привет! Подскажите, настроил repmgr, в конфиге /etc/repmgr.conf следующие строки: logfile='/var/log/postgresql/repmgr.log' loglevel='INFO' но файл repmgr.log не создаётся, ни на мастере ни на слейве, подскажите в чём может быть проблема?

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

что-то типа дефрагментации по пользователю?)

что-то типа дефрагментации по пользователю?)

да! :)

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

но данные динамические, и чаще всего нужны те самые, последние, которые лежат как пришли :)

а партицировать по часам не поможет?

почему обязательно по часам? потому что так в примере в книжке написато? пусть по юзеру партиционирутся же

100500 частей правда будет

ERROR: S client not available

100500 частей правда будет

Партиция по сотням пользователей

ну или по первым буквам логина пользователя

почему обязательно по часам? потому что так в примере в книжке написато? пусть по юзеру партиционирутся же

я ненастоящий сварщик, извините. согласен, по юзерам логичнее.

почему обязательно по часам? потому что так в примере в книжке написато? пусть по юзеру партиционирутся же

Но это настолько банально, что Дорофей эту гипотезу явно рассмотрел и отмел

Партиция по сотням пользователей

отлично! как отсчитать сотни пользователей и насоздавать партиций, если id - uuid? :)

@iamigor , использовать redis для хранения заранее подготовленного ответа (по user_id) - не?

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

Я таки начинаю понимать, когда MS SQL-щики говорят про клястерные индексы...

Дорофей нас просто немного тролит, он уже наверняка придумал решение и теперь просто ждёт подтверждение )

отлично! как отсчитать сотни пользователей и насоздавать партиций, если id - uuid? :)

Убрать uu. Пронумеровать

отлично! как отсчитать сотни пользователей и насоздавать партиций, если id - uuid? :)

перевести в инт96 (или какой там) и по диапазонам

но это всё накладные расходы...

Убрать uu. Пронумеровать

Переписывать приложение? Занятие не вот уж интересное.

Убрать uu. Пронумеровать

за "убрать uu" ребята сделают "убрать постгрес" и поставят монгу ;)

Дорофей нас просто немного тролит, он уже наверняка придумал решение и теперь просто ждёт подтверждение )

нет у меня решения, к сожалению. есть сколько-то путей обхода, но они так себе :)

за "убрать uu" ребята сделают "убрать постгрес" и поставят монгу ;)

Ну не убрать в прямом смысле, а добавить порядковый номер при добавлении пользователей. Хотя если они никак в БД не учитываются, а только прилетают в виде uuid c event'ами, то схема не работает

нет у меня решения, к сожалению. есть сколько-то путей обхода, но они так себе :)

Попробуй сделать партиций 2го уровня и мазать данные по uuid :) но придется искать партицию руками :)

Одна строка, так как поиск происходит по индексу, а он не разебан

извиняюсь за скорость. Студент как никак ))) попробуй по таблице пробежаться вот так: CREATE OR REPLACE FUNCTION "MySchema"."MyFunction"(out iCount integer) RETURNS integer as $$ declare keys integer; iCount integer default 0; curs1 cursor for select myID from "MySchema"."myTable"; begin open curs1; fetch curs1 into keys; if keys=2 then iCount=iCount+1; end if; close curs1; end $$ LANGUAGE plpgsql VOLATILE; только подставь свое. Это последовательный проход по таблице. На индексы не смотрит. Как раз и покажет сколько у тебя одинаковых значений которые ты укажешь в условии

Да я уже переключился на реплику

)))

Попробуй сделать партиций 2го уровня и мазать данные по uuid :) но придется искать партицию руками :)

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

Попробуй сделать партиций 2го уровня и мазать данные по uuid :) но придется искать партицию руками :)

а не руками опции есть? а то так copy делать не очень красиво получается :)

отлично! как отсчитать сотни пользователей и насоздавать партиций, если id - uuid? :)

по 256 юзеров: select get_byte(decode(md5(user.uuid::text),'hex'), 15);

нет у меня решения, к сожалению. есть сколько-то путей обхода, но они так себе :)

В порядке бреда, а если евенты складировать в табличку вида: user_id uuid, jsonb [] Где в массив валить некоторое разумное количество собственно евентов. Вопрос в критериях и значениях разумности. А так - в общем случае как-то грустно в этом плане всё.

В порядке бреда, а если евенты складировать в табличку вида: user_id uuid, jsonb [] Где в массив валить некоторое разумное количество собственно евентов. Вопрос в критериях и значениях разумности. А так - в общем случае как-то грустно в этом плане всё.

о, ну прям мой доклад с pgconf )) Для этого нужно иметь буффер + будет лаг скорее всего

В порядке бреда, а если евенты складировать в табличку вида: user_id uuid, jsonb [] Где в массив валить некоторое разумное количество собственно евентов. Вопрос в критериях и значениях разумности. А так - в общем случае как-то грустно в этом плане всё.

это будет update, это скорость втягивания относительно copy просадит

не говоря уж про toast :)

да, toast будет серьезный) Зато даннные пожмешь)

а не руками опции есть? а то так copy делать не очень красиво получается :)

с copy проблем быть не должно мне кажется. Будут проблемы на SELECT )

так уже :)

по 256 юзеров: select get_byte(decode(md5(user.uuid::text),'hex'), 15);

++, просто прикинуть максимальное количество юзеров и исходя из этого партиционировать по хэшу от идентификатора