❗Обновлен список услуг❗ - Восстановление сим-карт под QIWI, карты, соц.сети и пр. "Обговаривается" - Пробив местоположения через сим "погрешность 10-20 метров" - Пробив данных "ФИО и паспортные данные" - Детализация до 6 месяцев - Восстановление МТС, Билайн, Магафон, ТЕЛЕ2. "Стоимость зависит от номера" - Закрытые тарифы. Их очень много "Это те самые тарифы о которых Вы мечтали" - Сим-карты "только оптом" пустые/с балансом "МТС, Билайн, Магафон, ТЕЛЕ2" - Красивые номера, также подбор собственных вариантов. - Устройство для активации sim - Также есть услуги по WhatsApp "такого нет нигде!" Подробно в ЛС! ❗ПЕРЕЙДИ НА ЭТО КАНАЛ, ЧТОБЫ ПОСМОТРЕТЬ КОНТАКТЫ ❗

админы, куда вы смотрите.

❗Обновлен список услуг❗ - Восстановление сим-карт под QIWI, карты, соц.сети и пр. "Обговаривается" - Пробив местоположения через сим "погрешность 10-20 метров" - Пробив данных "ФИО и паспортные данные" - Детализация до 6 месяцев - Восстановление МТС, Билайн, Магафон, ТЕЛЕ2. "Стоимость зависит от номера" - Закрытые тарифы. Их очень много "Это те самые тарифы о которых Вы мечтали" - Сим-карты "только оптом" пустые/с балансом "МТС, Билайн, Магафон, ТЕЛЕ2" - Красивые номера, также подбор собственных вариантов. - Устройство для активации sim - Также есть услуги по WhatsApp "такого нет нигде!" Подробно в ЛС! ❗ПЕРЕЙДИ НА ЭТО КАНАЛ, ЧТОБЫ ПОСМОТРЕТЬ КОНТАКТЫ ❗

админы, куда вы смотрите.

не, ну может они используют pgsql

?

@Komzpa Пынь!

@pasha_golub Пынь

админы, куда вы смотрите.

Сорри, я в Киеве и тут интернет закончился в полночь :)

Сорри, я в Киеве и тут интернет закончился в полночь :)

В тыкву превратился? ?

админы, куда вы смотрите.

Мы иногда спим и занимаемся другими делами. Если есть вопросы, вызывать напрямую

А есть какой-нибудь опенсорос веб что бы на нём ещё тест провести

Sqlfiddle.com

А что, еще никто не написал антиспамбота для tg?

Можно организовать. Только баны будут автоматические и за оффтопик тоже :)

Можно организовать. Только баны будут автоматические и за оффтопик тоже :)

А если я буду писать "Салют чуваки... Я сделалъ - http://sram/.... бла... бла Любите postgres".... будет в офтоп попадать?

Тут сразу видится два пути решения: 1) Нечто байесо-подобное 2) реакция на форварженные верифицированными участниками сообщения

Тут сразу видится два пути решения: 1) Нечто байесо-подобное 2) реакция на форварженные верифицированными участниками сообщения

Второе уже есть. Это мы ?

Второе уже есть. Это мы ?

А у вас есть SLA с доступностью хотя бы 98?

А у вас есть SLA с доступностью хотя бы 98?

Есть. Платная подписка. ?

Есть. Платная подписка. ?

Вот так и знал. Опенсорс, но с подпиской. ))

Вот так и знал. Опенсорс, но с подпиской. ))

Саппорт же ?

Всем привет. Какие различия в партицировании с правилами против функции(с триггерами)?

Всем привет. Какие различия в партицировании с правилами против функции(с триггерами)?

А с правилами это как?

`CREATE RULE INSERT_INTO_TEN_MINUTES AS ON INSERT TO ONEMINUTE WHERE ( EXTRACT(MINUTE FROM DATE_TIME)=(EXTRACT(MINUTE FROM(TO_TIMESTAMP(FLOOR((EXTRACT('EPOCH' FROM DATE_TIME) / 600 )) * 600))))) DO INSERT INTO TEN_MINUTE VALUES(NEW.*)`

`CREATE RULE INSERT_INTO_TEN_MINUTES AS ON INSERT TO ONEMINUTE WHERE ( EXTRACT(MINUTE FROM DATE_TIME)=(EXTRACT(MINUTE FROM(TO_TIMESTAMP(FLOOR((EXTRACT('EPOCH' FROM DATE_TIME) / 600 )) * 600))))) DO INSERT INTO TEN_MINUTE VALUES(NEW.*)`

А как новые партиции создавать?

ручками :D ну можно через цикл прогнать на создание их. Или в этом и есть загвоздка?

ручками :D ну можно через цикл прогнать на создание их. Или в этом и есть загвоздка?

Ну руками это не интересно. А вот в триггере автоматом делается.

Ну руками это не интересно. А вот в триггере автоматом делается.

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

не-не, а как например создать триггер который создает партицию при условии

например id>100

то создает партицию и т.д

Я ведь правильно понимаю что для каждой партиции свое правило?

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

да, это так

не-не, а как например создать триггер который создает партицию при условии

Он так и работает. Какое условие задаешь, с таким и создает.

спасибо =)

спасибо =)

Если есть возможность протестируй производительность. С триггерами и с правилами. Потом отпиши.

постараюсь. уже один минус у правил есть это написание для каждой партиции правила

ну можно автоматизировать, да

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

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

А с правилами будет так что все правила будут проверяться. Я так думаю. И при 100 партициях думаю будет просадка в скорости.

pg_partman позволяет создавать партиции на каждый год?

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

@LulzSc лучше pg_pathman возьмите )

если хотите через расширение

ааааа он у меня не ставится(а pg_partman пока не ставил)

т.е это же автоматизация процесса, задаешь ему какие-то условия и все?

Странная штука. Мониторинг ругнулся что на диске место заканчивается. Оказывается WAL перестал архивироваться и копится в pg_xlog начал разбираться. Оказалось что такой файл в архиве уже есть. Переименовал, все заархивировалось и удалилось с pg_xlog. Однако не совсем все. Текущий файл 00000001000000480000008F однако в pg_xlog есть еще несколько файлов, самый старый из которых 000000010000004800000090. Имя у него такое что он должен быть новей текущего, однако он довольно старый и датирован началом февраля.

postgresql-9.5.6

Тут сразу видится два пути решения: 1) Нечто байесо-подобное 2) реакция на форварженные верифицированными участниками сообщения

как в ирц =) есть бот, у него админские права и банхаммер. есть человеки которым выдано им рулить, нет одминов - банит бот с лёгкой руки старожилов.

привет! Есть потребность в больших (за многие миллионы или сотни тысяч рублей) уже написанных ТЗ. конфиденциальность гарантируется. они нужны не для прямого назначения)) Прошу откликнитесь те у кого есть возможность их раздобыть

а тут есть студенты, которые не знают, чего делать летом? :) мы с @Gardster менторим на Google Summer of Code в организации OpenStreetMap. Если кто-то хочет получить в резюме опыт миграции схемы шеститерабайтной базы, можно подаваться :) осмовские идеи живут на https://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2017/Project_Ideas

А с правилами будет так что все правила будут проверяться. Я так думаю. И при 100 партициях думаю будет просадка в скорости.

Правила встраиваются на уровне запроса, а триггер на уровне исполнения

а тут есть студенты, которые не знают, чего делать летом? :) мы с @Gardster менторим на Google Summer of Code в организации OpenStreetMap. Если кто-то хочет получить в резюме опыт миграции схемы шеститерабайтной базы, можно подаваться :) осмовские идеи живут на https://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2017/Project_Ideas

Есть

Есть

ты ведь сможешь проследовать по ссылке и разобраться? :)

ты ведь сможешь проследовать по ссылке и разобраться? :)

Следую, читаю

а тут есть студенты, которые не знают, чего делать летом? :) мы с @Gardster менторим на Google Summer of Code в организации OpenStreetMap. Если кто-то хочет получить в резюме опыт миграции схемы шеститерабайтной базы, можно подаваться :) осмовские идеи живут на https://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2017/Project_Ideas

ох. где ты был год назад...)

или я:)

покидайте годных статей по написаниям функции в postgresql

ну такой бестпрактис

ERROR: S client not available

best practice - не писать хранимки

best practice - не писать хранимки

Это почему же?

потому что все превращается в тыкву еще до наступления полуночи

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

логика - приложению, данные - бд

Позволю себе не согласиться. Знаю много успешных проектов, где часть логики (а где-то и вся логика) была инкапсулирована в БД. Это позволяет скрыть часть внутренней кухни от клиента. Особенно удобно, например, для всяких отчётов - базист пишет хранимку, которая отдаёт данные, приложение просто вызывает. При таком подходе базист отвечает за то, как будут выполняться запросы и обновление логики не требует обновления приложения.

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

мне кажется это просто добовляет новый слой, который требует согласований в случаех каких либо изменений

какой смысл обновлять логику в отрыве от приложения?

версионирование усложняется ещё больше

Кто-то вообще даже доступ к данным таким образом разграничивает. Пользователь "логинится" в базе перед выполнением запросыа, например select auth(login, password), а потом вызывает другие хранимки и доступ к данным проверяется прямо внутри хранимок. Например, пользователь какого-нибудь филиала видит только те данные, которые ему положены.

версионирование усложняется ещё больше

Ничего подобного. Как раз наоборот. Хранимки можно класть в репку и видеть всю историю изменений.

какой смысл обновлять логику в отрыве от приложения?

Почему в отрыве? Если надо просто ошибку в отчёте исправить, например. Поправил хрунимку и всё.

это делается проще и дебажнее внутри приложения, нежели искать потом, в какой ранимке выдали доступ

Почему в отрыве? Если надо просто ошибку в отчёте исправить, например. Поправил хрунимку и всё.

потому что приложение в этом случае ни о чем не знает

Правильно, ему и не надо )

Ничего подобного. Как раз наоборот. Хранимки можно класть в репку и видеть всю историю изменений.

как раз не наоборот. внедряется еще один вид API, который при любом изменении интерфейса грозит положить все целиком

Позволю себе не согласиться. Знаю много успешных проектов, где часть логики (а где-то и вся логика) была инкапсулирована в БД. Это позволяет скрыть часть внутренней кухни от клиента. Особенно удобно, например, для всяких отчётов - базист пишет хранимку, которая отдаёт данные, приложение просто вызывает. При таком подходе базист отвечает за то, как будут выполняться запросы и обновление логики не требует обновления приложения.

Полностью согласен. Если у БД может быть несколько разных клиентов, то логике в хранимках может быть самое подходящее место

Ладно, это и правда холиварная тема, на самом деле. Каждый делает, как ему удобно.

Правильно, ему и не надо )

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

Основной для меня плюс в том, что разработчик клиентского приложения может не знать всех тонкостей написания запросов (про ORM вообще молчу) и конкретной СУБД. Поэтому всё, что связано с базой отдаётся на откуп базисту.

блин, ну по функциям киньет что-нибудь

=)

опят ьразработчик неуч и вообще виноват

Разработчик априори неуч) У нас на днях дбашник предложил распять разработчика без права помилования (что как бэ само по себе невозможно).

блин, ну по функциям киньет что-нибудь

Перевод официальной документации: https://postgrespro.ru/docs/postgrespro/9.6/server-programming.html Первоисточник - он и есть первоисточник.

1. Когда надо перелопатить большой объем данных это удобнее делать в базе данных, это более эффективно, чем гнать тонны данных на клиента (сервер приложений) 2. Работа с данными эффективнее - sql для этого и создан 3. Когда надо подцепиться другим клиентом не требуется писать какой-то апи к существующему серверу приложений 4. Версионируется отлично. У нас вообще была одна разработческая база в которую все писали. Я прикрутил DDL триггеры, вся история автоматом в гит писалась

есть еще вариант, когда хранимый код берется из гита и заливается в БД в рамках одной транзакции вместе с тестами