но где-то слово докер там точно фигурировало))

простите, что такое "работает через докер" в контексте винды?

Это вот такое вот. :) Чтобы жЫзнь мёдом не казалась.

и я не про докер-через-виртуалку

А есть на прямую? ?

https://www.docker.com/docker-windows-server

но где-то слово докер там точно фигурировало))

нет там нигде докера, WSL - windows subsystem for linuх

нет там нигде докера, WSL - windows subsystem for linuх

а, ну отлично тогда, хорошо, что показалось

Короче, есть hyper-v containers со своей спецификой, они там реестр как-то мучали, еще что-то делали, но это реально не linux + cgroups. В каком оно сейчас состоянии - я не знаю, что скачается по запросу просто "docker for windows", тоже не знаю.

https://www.docker.com/docker-windows-server

Прикольно, сделали наконец, а то раньше у них все было через виртуалбокс

так, я смотрю, тут опять треш начинается. За чаем уже стоит иттить? Докер для винды - это докер для винды. Никакого отношения к упомянутой Windows subsystem for Linux, где запускается убунта (о чём начался разговоро) оно не имеет.

она через докер работает вродь)

Нет, она через бридж виндовый

Друззя, СУБД Tibero от TmaxSoft — это не клон ПГ часом? Кто-то слышал про сие энтерпрайз решение?

Это клон оракла

Друззя, СУБД Tibero от TmaxSoft — это не клон ПГ часом? Кто-то слышал про сие энтерпрайз решение?

Это китайский клон оракле если про то помню

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

Интернеты пишутЪ, что корейский клон оракела.

они пошли так далеко что даже oci повторили полностью

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

Ну и потоки, упоминающиеся в описаниях, явно указывают, что это не ПГ .

Привет, Народ! Кто в курсе, если приобрести лицензию postgres pro на 24 ядра. ее потом можно же использовать потом на других серверах с таким же количеством ядер или отдельно на каждый покупать? И срок действия лицензии какой?

Привет, Народ! Кто в курсе, если приобрести лицензию postgres pro на 24 ядра. ее потом можно же использовать потом на других серверах с таким же количеством ядер или отдельно на каждый покупать? И срок действия лицензии какой?

Я даже не знал что оно по ядрам лицензируется :(. Расскажи пожалуйста почем обошлось?

Привет, Народ! Кто в курсе, если приобрести лицензию postgres pro на 24 ядра. ее потом можно же использовать потом на других серверах с таким же количеством ядер или отдельно на каждый покупать? И срок действия лицензии какой?

Можно использовать на том количестве ядер что куплено. Срок действия лицензии зависит от лицензии. Есть постоянные есть на определенный срок

Пока просчитываем чего нам вообще нужно, для гос закупок! как определимся, отпишусь сюда, в итоге что по цифрам получается ... Пока цифра 120k за ядро

PPS-86-LIC

Можно использовать на том количестве ядер что куплено. Срок действия лицензии зависит от лицензии. Есть постоянные есть на определенный срок

были же опции "на машинах разработчиков бесплатно", или мне показалось?

знатоки pglogical, подскажите, почему он реплицирует сиквенсы со значением на 1000 больше? Что это за кэш такой? Как заставить его реплицировать 1 к 1-му?

были же опции "на машинах разработчиков бесплатно", или мне показалось?

Конечно есть. Тестовые системы и разработка лицензий не требуют

PPS-86-LIC

Это сертифицированная ФСТЭК версия. Лицензия постоянная. Год поддержки входит в лицензию

Это сертифицированная ФСТЭК версия. Лицензия постоянная. Год поддержки входит в лицензию

А на других серверах с 24 ядрами можно тоже размещать ее на сколько я понимаю .... ?

знатоки pglogical, подскажите, почему он реплицирует сиквенсы со значением на 1000 больше? Что это за кэш такой? Как заставить его реплицировать 1 к 1-му?

это фича такая, используется динамический буфер, когда реплики получают значения сиквенсов с опережением, чтобы избежать конфликтов. подробности в документации (раздел 4.10 "Sequences"). хотя их там немного: https://www.2ndquadrant.com/en/resources/pglogical/pglogical-docs/

А на других серверах с 24 ядрами можно тоже размещать ее на сколько я понимаю .... ?

Не важно сколько серверов. Формально по лицензии нужно чтобы одномоментно в эксплуатации было не более 24 ядер на серверах с Postgres. Однако могут быть проблемы с аттестацией систем включающих сертифицированную субд. Если вы перестроите систему, это может потребовать ее переаттестации. Точно не знаю, это лучше узнать у спецов по безопасности.

Не важно сколько серверов. Формально по лицензии нужно чтобы одномоментно в эксплуатации было не более 24 ядер на серверах с Postgres. Однако могут быть проблемы с аттестацией систем включающих сертифицированную субд. Если вы перестроите систему, это может потребовать ее переаттестации. Точно не знаю, это лучше узнать у спецов по безопасности.

Спасибо большое за консультацию.

Спасибо большое за консультацию.

Не за что. Это наша работа. Хоть и отпуск ;)

Подскажите пожалуйста, есть ли способ интеграции PostgreSQL с DB2

через FDW

и что для этого нужно, подскажите пожалйста)_

что подразумевается под интеграцией?

вообще не слышал чтоб в пг было понятие присоединенного сервера. но я не настоящий сварщик

вообще не слышал чтоб в пг было понятие присоединенного сервера. но я не настоящий сварщик

Почитай про Foreign Data Wrappers

Подскажите пожалуйста, есть ли способ интеграции PostgreSQL с DB2

почитай этот тред https://www.postgresql.org/message-id/CAMU5o%2B9kLiN1gMGA965yAQ5ZkrJ0On5QNK2orL9m_hnm9MUPEw%40mail.gmail.com

Почитай про Foreign Data Wrappers

нет, спасибо, мне и так хорошо ) но теперь могу говорить что таки слышал ))

ты смотри, оказывается есть врапперы к гит, гуглу, фейсбуку, твиттеру...

...и PBF!

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

и на перле?

А есть примеры простейшего враппера на любом языке?

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

CSS 42.5% C 26.3% JavaScript 15.0% Protocol Buffer 6.9% PLpgSQL 3.9% HTML 2.8% Makefile 2.6% это как раз https://github.com/vpikulik/postgres_osm_pbf_fdw например ))

Привет, подскажите, плиз. Каких прав не хватает ?

ad_master_1_main=> select api.set_adv_gross_fall_repot_settings(100,0.8,0.95); ERROR: permission denied for relation settings CONTEXT: SQL statement "update settings s set s_value = sp_value where upper(s.s_code) = upper(sp_code) and upper(s.s_owner) = upper(coalesce(sp_owner, user::text))" PL/pgSQL function set_setting(character varying,text,character varying) line 3 at SQL statement SQL statement "SELECT set_setting('ADV_FALL_GROSS_MIN',np_gross_min::text,'postgres'), set_setting('ADV_FALL_GROSS_PERCENT',np_gross_percent::text,'postgres'), set_setting('ADV_FALL_GROSS_PERCENT_DIFF_DAY',np_gross_percent_diff_day::text,'postgres')" PL/pgSQL function api.set_adv_gross_fall_repot_settings(numeric,numeric,numeric) line 3 at PERFORM

А какие ты выдавал?

А какие ты выдавал?

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA api TO barsukov; И GRANT USAGE ON SCHEMA api TO barsukov;

А гранты выдавались до или после создания таблиц?

Если до, то надо выдавать заново. Предварительно определив DEFAULT PRIVILEGES, как описано в документации: https://www.postgresql.org/docs/9.6/static/sql-alterdefaultprivileges.html

А также было бы неплохо глянуть на вывод \dt, \dt api.* и тело проблеммной ф-ии.

Вопрос к знатокам пг может быть быстрее редиса по выборке по ПК?

ну ты отчего уверен? вот мы 2 месяца исследовали измеряли, отключили редис и на 20-30% быстрее стали, что мы сделали не так?

повторяю это работает на ограниченных случаях

От понимания того как работают запросы в ключ/значение системах и субд

ну а практика показывает иные результаты порой. если копнуть вглубь то тому есть объективные причины

редис как и все остальные кэши нужны на больших базах и занчительной нагрузке

Конечно же, с радостью рассмотрю конкретный кейс и бенч к нему

на средних очень вероятно что нет

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

Скорее, нет.

ERROR: S client not available

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

Скорее всего, вы правильно готовили постгресс, и не правильно редис.

И я не помню, что там у редиса с многопоточностью. Если он однопоточный, то на 16 ядрах постгрес мог его догнать.

Если кэш протухал часто и быстро, то лишняя прослойка конечно вас тормозила.

редис однопоточный

обгонял постгресом редис на ноуте с 4 ядрами

:-) забавно. Запросом по pk?

сча в схему гляну, 2014 был

:-) забавно. Запросом по pk?

https://github.com/Komzpa/fidelity/blob/master/databases/offline/init.sql

постгрес разве сам по себе многопоточный?

Я могу ошибаться, но я вижу полноценный селект с условиями, сортировкой и limit 1, против выборки в цикле n ключей отдельными запросами в редис с последующей сортировкой в питоне.

сама дискуссиия ээээ блещет аргументами

но с условием того, что есть всякие page cache, постгрес тоже может не касаться диска вообще

постгрес разве сам по себе многопоточный?

Многопроцессный. Правильно его приготовив, можно все ядра напрячь​. Хотя согласен, что одним запросом это сделать не просто.

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

но с условием того, что есть всякие page cache, постгрес тоже может не касаться диска вообще

В постгрессе по cpu очень много оверхеда. "select * from mytable where id=$1" ни когда не будет таким же быстрым, как get в redis.

много это сколько? микросекунды?

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

Один коннект - один процесс. Два коннекта - два процесса. Сто коннектов - сто процессов.

Один коннект - один процесс. Два коннекта - два процесса. Сто коннектов - сто процессов.

это коннекты. а непосредственно запросы где выполняются?

много это сколько? микросекунды?

Это 300000rps vs 30000rps.

В постгрессе по cpu очень много оверхеда. "select * from mytable where id=$1" ни когда не будет таким же быстрым, как get в redis.

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

это коннекты. а непосредственно запросы где выполняются?

Запрос выполняется в процессе коннекта.

Запросы одного коннекта - в одном процессе. Другого коннекта - в другом процессе... Сотого коннекта - в сотом процессе.

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

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

Про rps не можешь, т.к. взято из головы. На самом деле, redis еще быстрее, а постгресс - еще медленнее. Но это если говорить про одно ядро cpu. А про коннекты - RTFM.

Эта дискуссия только что стала еще прекрасней той

Я хотел и по русски добавить, но вряд ли это поменяет что-либо.

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

В любом случае, чтение мануалов - действие полезное.

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

я просто вот прямо сейчас читаю Helper processes like background writer and wal writer offload I/O requirements from the main query execution process

Читай больше, глубже, до прозрения.