да не за что )))

вем привет,какой тип данних использовать для числа от 0.0 до 100.0?

смотря какие требования

вем привет,какой тип данних использовать для числа от 0.0 до 100.0?

enum! CREATE TYPE mynums AS ENUM ('0.0', '0.1', ... , '100.0');

а если серьезно, то https://www.postgresql.org/docs/9.6/static/datatype-numeric.html читайта про numeric

Всем привет

Вот есть у меня запрос. Не поможете его упростить, а то на продакшене - он 3 секунды выполняется - много. SELECT user_email, dc.count camera_cc, tc.count server_cc, sc.count service_cc FROM _users LEFT JOIN (SELECT user_email, count(device_guid) count FROM _devices WHERE device_type = 'Camera' GROUP BY user_email ) AS dc USING (user_email) LEFT JOIN (SELECT user_email, count(device_guid) count FROM _devices WHERE device_type = 'Server' GROUP BY user_email ) AS tc USING (user_email) LEFT JOIN (SELECT user_email, count(service_id) count FROM _services LEFT JOIN _resources ON _services.resource_id = _resources.resource_id LEFT JOIN _devices USING (device_id) GROUP BY user_email) AS sc USING (user_email);

Было бы неплохо посмотреть на мощь участвующих таблиц (хотя бы порядок количества записей) и EXPLAIN ANALIZE. Ну это для начала.

А так в таблице юзеров в районе 300к записей. В девайсах примерно в 10 раз больше.

Нужен вывод команды EXPLANE ANALIZE

также сильно интересует объём оперативной памяти и, для начала, значение shared_buffers

Как такие красивые картиночки рисуете, если не секрет?

Как такие красивые картиночки рисуете, если не секрет?

pg_admin3 же

Вообще вот тут вроде красивее рисуют: http://tatiyants.com/postgres-query-plan-visualization/

Вообще вот тут вроде красивее рисуют: http://tatiyants.com/postgres-query-plan-visualization/

Ого, спасибо за ссылку!

Ого, спасибо за ссылку!

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

Еще и опенсорс

Всем привет! Есть столбец с текстовым полем

Все значения в ней уникальны

это нормально использовать её в качестве первиного ключа?

Или лучше айдишники запилить?

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

а так вообще первичный ключ в таблице необязательное явление

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

да

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

не то что зло, просто есть возможность огрести

не то что зло, просто есть возможность огрести

а в чем?

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

gis=# create table aaa (id text primary key); CREATE TABLE gis=# insert into aaa SELECT array_to_string(ARRAY( SELECT chr((ascii('B') + round(random() * 25)) :: integer) FROM generate_series(1,100005)), ''); ERROR: index row requires 100024 bytes, maximum size is 8191

например, окажется, что нельзя сделать больше 8191 байта строки, потому что btree не умеет

это не проблема семантики, это проблема btree, которым сделан unique / pkey но когда огребёшь, скажут "а надо было числовые делать" :)

Ребят, а в pg 9.5 ограничить коннекты по ip для конкретных юзеров можно только через конфиг? На лету никак?

Ребят, а в pg 9.5 ограничить коннекты по ip для конкретных юзеров можно только через конфиг? На лету никак?

я не шарю, но может проще это сделать через пгбаунсер?

Ребят, а в pg 9.5 ограничить коннекты по ip для конкретных юзеров можно только через конфиг? На лету никак?

pg_hba.conf

Ребят, а в pg 9.5 ограничить коннекты по ip для конкретных юзеров можно только через конфиг? На лету никак?

iptables ?

iptables ?

как реализовать такое для разных юзеров?

как реализовать такое для разных юзеров?

pg_hba + reload, он так-то тоже на лету

ты написал айпитеблс

мне вот интересно стало))

"ограничить коннекты по ip для конкретных юзеров" в iptables? Мне вот тоже интересно.

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

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

ну уж тогда напиши модуль для постгреса...

норм так юзерам отвечать)))

Можно попробовать собрать такое в рамках PAM-аутентификации и подключить штатно в Postgres

а постгре через пам ходит?

а постгре через пам ходит?

Не "через пам" а может использовать PAM как механизм аутентификации. https://www.postgresql.org/docs/current/static/auth-methods.html

Можно например его убедить использовать /etc/shadow вместо своей внутренней аутентификации

даже лдап умеет, прикольно))

Ребят, нужен ваш совет по постгресу(9.6) Есть веб-сервис ненагруженный и из него периодически делается большой отчет, который минут 10 генерится. Отчет не на sql, а в питоне сделан. много запросов. И есть такая проблема - за то время, пока он генерится что-то меняется в базе и отчет становится неверным. Все транзакции сейчас read commited. Есть иде обернуть генерацию отчета в serialisable. Отчет это readonly операция. Судя по документации, это норм. 2 вопроса - 1)могут ли обычные транзакции или сам отчет упасть с serialization anomaly? (вроде нет, но не уверен) 2) видити ли вы какие-то подводные камни в этом рещении?

> сам отчет упасть с serialization anomaly? > detection of the conditions which could cause a serialization anomaly will trigger a serialization failure.

Ребят, нужен ваш совет по постгресу(9.6) Есть веб-сервис ненагруженный и из него периодически делается большой отчет, который минут 10 генерится. Отчет не на sql, а в питоне сделан. много запросов. И есть такая проблема - за то время, пока он генерится что-то меняется в базе и отчет становится неверным. Все транзакции сейчас read commited. Есть иде обернуть генерацию отчета в serialisable. Отчет это readonly операция. Судя по документации, это норм. 2 вопроса - 1)могут ли обычные транзакции или сам отчет упасть с serialization anomaly? (вроде нет, но не уверен) 2) видити ли вы какие-то подводные камни в этом рещении?

Может все запросы сделать в самом начале (может даже за один запрос) и процессить на питоне сколько хочется?

Может все запросы сделать в самом начале (может даже за один запрос) и процессить на питоне сколько хочется?

так не получится. все сильно декомпозированно и сотни таблиц и шаблонов участвуют в этом

> сам отчет упасть с serialization anomaly? > detection of the conditions which could cause a serialization anomaly will trigger a serialization failure.

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

Ну, приложение же у тебя пишет в это время?

да. но с уровнем изоляции read commited

по идее readonly serialisable транзакция просто не должна это видеть. это то, что мне надо

ERROR: S client not available

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

уровень изоляции в другой транзакции не играет роли

Не может же транзакция держать в памяти полный слепок данных в БД на момент ее старта.

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

Не может же транзакция держать в памяти полный слепок данных в БД на момент ее старта.

snapshot isolation же

хммм

Да ты прав, ну тогда это рабочее решение.

Можно его проверить, написав маленькую эмулирующую программу.

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

repeatable от serialisable отличается в основмном тем, что первый видит новые записи, а второй нет. измененные они оба не видят. и мне нужен второй

это не проблема семантики, это проблема btree, которым сделан unique / pkey но когда огребёшь, скажут "а надо было числовые делать" :)

спасибо, я понял :)

ребята, так на вопрос кто-нить может ответить?)

The Repeatable Read isolation level only sees data committed before the transaction began; it never sees either uncommitted data or changes committed during transaction execution by concurrent transactions.

serializable на длинные вещи точно нельзя ставить

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

Можно использовать serializable, но могут быть проблемы, вызванные блокировками.

а что именно блокироваться будет?

я сделал ручное тестирование и есть тесты на это. все работает. но мне нужна консультация бывалых

Serializable Isolation Level ... If either transaction were running at the Repeatable Read isolation level, both would be allowed to commit; ... Т.е. для обеспечения Serializable надо, чтобы все остальные также были Serializable. https://www.postgresql.org/docs/9.6/static/transaction-iso.html И оно же на русском: https://postgrespro.ru/docs/postgrespro/9.6/transaction-iso.html

Так что, если вокруг read committed, то выше repeatable read ставить просто не имеет смысла.

Т.е. для обеспечения Serializable надо, чтобы все остальные также были Serializable. - откуда такой вывод? у меня readonly resialasable транзакция. конфкликтов в принципе быть не может

Если бы одна из этих транзакций работала в режиме Repeatable Read, зафиксироваться могли бы обе; - мне достаточно этой фразы, чтобы сделать вывод о том, чтобы обеспечить Serializable, надо всё вокруг делать Serializable. Вы можете думать по-другому.

я думаю, что это не так

Проверьте. Делов-то.

это потому что serializable гаранитирует "аномалия сериализации Результат успешной фиксации группы транзакций оказывается несогласованным при всевозможных вариантах исполнения этих транзакций по очереди."

а что именно блокироваться будет?

Я имел в виду предикатные блокировки: https://stackoverflow.com/questions/12837708/predicate-locking-in-postgresql-9-2-1-with-serializable-isolation

да я проверял) и все работает