Мама! Хотя это уже было.

Вы просто хейтеры виндовые. А мне пофиг какая система, лишь бы работала )

Сколько стоит апгрейд Maс OS ?

бесплатно

Так и делал до Докера. Теперь без него никак ))

Это по причине докера. C VBox не все как нужно

бесплатно

Да ладно? )) Это память увеличить или HDD в 2 раза бесплатно? ))

Да ладно? )) Это память увеличить или HDD в 2 раза бесплатно? ))

а зачем? SSD наверное? HDD уже нету.

Вы просто хейтеры виндовые. А мне пофиг какая система, лишь бы работала )

+ религиозники что с них взять =)

а зачем? SSD наверное? HDD уже нету.

Вот вы интересные. Сегодня данные занимают один объем, завтра другой. Требования к оперативке при обработке тоже растут. Мы же тут про базы, нет? От вас это особенно странно. Даже требования к разработке web-фронтенда растут.

Все прочли статью, про джойны, которую ранее кинули в канал?

Вот вы интересные. Сегодня данные занимают один объем, завтра другой. Требования к оперативке при обработке тоже растут. Мы же тут про базы, нет? От вас это особенно странно. Даже требования к разработке web-фронтенда растут.

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

Я уже в 16 гб оперативки еле влажу.

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

А, я пожалуйста. Мне не жмет )

Кстати, на рутрекере есть две части видеокурсов по постгре! На русском, с лабами\сырцами! От установки и админства, до прогерства с ньюансами... Полезно и смотрибельно! Рекомендую.

а есть ссылка? :)

сек... ищу...

https://postgrespro.ru/education

Не учебные курсы с этой странички, случайно?

Ибо на русском - ещё куда ни шло, но с лабами и сырцами...

вот: 1. Базовый курс https://rutracker.org/forum/viewtopic.php?t=5206279 2. Расширенный курс https://rutracker.org/forum/viewtopic.php?t=5252709

Остальное где-то в архиве дома... ((( Надо искать

Ага, они самые.

Ага, они самые.

Не зашли?

У нас новички на ура просмотрели... А потом литературкой и практикой закрепили...

Не зашли?

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

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

А, в этом ключе! Извини, недопонял. (

Вот базовый курс: https://postgrespro.ru/education/courses/DBA1

Вот расширенный: https://postgrespro.ru/education/courses/DBA2

Там все материалы, имеющиеся в наличии, в отличие от трекера.

Да! Хороший сайт.

Там все материалы, имеющиеся в наличии, в отличие от трекера.

Трекер тоже содержит видео и файло... см. сам

Но, по вкусу... кто с сайта, кто с трекера... А можно и совместить, по любому на сайте еще куча инфы нужной!

Да! Хороший сайт.

Ну вы, блин, даёте, я регулярно оттедова ссылки на документацию выдаю. :)

Трекер тоже содержит видео и файло... см. сам

Ага, и в теме ссылка на оригинал :)

Ну вы, блин, даёте, я регулярно оттедова ссылки на документацию выдаю. :)

Я не параноидально отслеживаю... У меня в закладках он есть и я не вкл. моск, что у кого-то этого сайта нет в ссылках )))

Ага, и в теме ссылка на оригинал :)

Ок, а почему нет-то! Там и на ютюб ссыль... Все четко и иныормативно, со всех источников... Достаточно полную инфу предоставили...

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

кроме чувства прекрасного - особых причин вроде как нет

хоть не template1

https://postgrespro.ru/education

Спасибо :)

хоть не template1

?? template[0|1]

@ExileeD Спасибо огромное! С volume работает :)

Ребят. Есть индекс на boolean столбец. В выборке стоит column = true индекс подключается и работает. А если в условии выборки column = false, то индекс не используется. Что за особенности такие? Тут на просторах нашлось крайне странное решение, использовать индекс на результат функции, которая булево отдает в int и использовать ее же в условиях выборки. Это решение работает, работает быстро. Но что не так с обычным boolean? По сути это ж int представление, даже сам постгрес так считает, но не использует индекс при false.

Ребят. Есть индекс на boolean столбец. В выборке стоит column = true индекс подключается и работает. А если в условии выборки column = false, то индекс не используется. Что за особенности такие? Тут на просторах нашлось крайне странное решение, использовать индекс на результат функции, которая булево отдает в int и использовать ее же в условиях выборки. Это решение работает, работает быстро. Но что не так с обычным boolean? По сути это ж int представление, даже сам постгрес так считает, но не использует индекс при false.

Селективность? )

Ребят. Есть индекс на boolean столбец. В выборке стоит column = true индекс подключается и работает. А если в условии выборки column = false, то индекс не используется. Что за особенности такие? Тут на просторах нашлось крайне странное решение, использовать индекс на результат функции, которая булево отдает в int и использовать ее же в условиях выборки. Это решение работает, работает быстро. Но что не так с обычным boolean? По сути это ж int представление, даже сам постгрес так считает, но не использует индекс при false.

cколько значений false в таблице относительно true?

Селективность? )

к чему? в чем?

cколько значений false в таблице относительно true?

false/true ~ 80/20

Вот именно поэтому и не используется. Как сказал Андрей - селективность индекса

ssd и random_page_cost стоит в 4, а не в 1.1? :)

а что статистика говорит? SELECT attname As colname, n_distinct, array_to_string(most_common_vals, E'\n') AS common_vals, array_to_string(most_common_freqs, E'\n') As dist_freq FROM pg_stats WHERE schemaname = 'public' and tablename = 'table' and attname = 'column';

к чему? в чем?

Если строк с column = false (условно) больше, чем с column = true, то использовать индекс СУБД выходит дороже, чем просто прочитать таблицу и не надо её в таком случае заставлять это делать.

Если строк с column = false (условно) больше, чем с column = true, то использовать индекс СУБД выходит дороже, чем просто прочитать таблицу и не надо её в таком случае заставлять это делать.

Спасибо.

но дефолты выставлены в "у нас магнитный вращающийся диск", а не в "у нас SSD", поэтому random_page_cost = 1.1 может разрешить использовать этот индекс, и это стоит сделать, если SSD

Если строк с column = false (условно) больше, чем с column = true, то использовать индекс СУБД выходит дороже, чем просто прочитать таблицу и не надо её в таком случае заставлять это делать.

А вот тогда в догонку вопрос. С результатом индекса от функции стоимость выборки в explain значительно ниже, чем когда boolean. Почему так?

потому что эстиматор - он на то и эстиматор, чтобы делать быстрые грубые прикидки если у него нет статистики, он берёт константу на количество

а статистики по функциям у него обычно нет

потому что эстиматор - он на то и эстиматор, чтобы делать быстрые грубые прикидки если у него нет статистики, он берёт константу на количество

Спасибо

А вот тогда в догонку вопрос. С результатом индекса от функции стоимость выборки в explain значительно ниже, чем когда boolean. Почему так?

Это обман планировщика просто получается. Данные быстрее выбираться не будут.

всем привет, можно ил полностью отключить автовакуум? https://www.oslogic.ru/knowledge/638/optimizatsiya-postgresql-autovacuum-sborka-musora/ тут говорится|, что почему-то нельзя , все-равно будет работать. как так ?

Я вот подумал, если человек хочет приключений на собственную пятую точку, надо этих приключений ему насыпать. Пусть развлечётся. В общем, совсем выключить автовакуум не получится. От слова совсем. Но можно серьёзно увеличить интервал между запусками: autovacuum = off autovacuum_freeze_max_age = 2000000000 # (2 млрд) Больше двух млрд подыскать трудновато будет. Но и этого хватит, чтобы ПГ быстро-быстро добрался до wraparound-а. Вот документация: https://postgrespro.ru/docs/postgrespro/9.6/routine-vacuuming.html п. 25.1.5 так, про врапэраунд предупредил? Предупредил. Пусть человек развлекается.

Я вот подумал, если человек хочет приключений на собственную пятую точку, надо этих приключений ему насыпать. Пусть развлечётся. В общем, совсем выключить автовакуум не получится. От слова совсем. Но можно серьёзно увеличить интервал между запусками: autovacuum = off autovacuum_freeze_max_age = 2000000000 # (2 млрд) Больше двух млрд подыскать трудновато будет. Но и этого хватит, чтобы ПГ быстро-быстро добрался до wraparound-а. Вот документация: https://postgrespro.ru/docs/postgrespro/9.6/routine-vacuuming.html п. 25.1.5 так, про врапэраунд предупредил? Предупредил. Пусть человек развлекается.

можно сразу выдать визитку pgpro, чтобы чинить с gdb, когда умрёт :)

Даааа, у нас админы как-то отрубили автовакуум. Wraparound долго ждать не пришлось.

Умный поиск На БД PostGreSQL создать две таблицы: список сотрудников (ФИО, отдел, должность) и список адресов этих сотрудников. Создать связь между таблицами. В Nodejs приложении создать http метод для поиска по сотрудникам. Поиск должен быть осуществлен по трем полям в этих двух таблицах: ФИО, должность, адрес. Это должен быть умный поиск (smart search), т.е. будет одно поле поиска и можно будет написать несколько ключевых слов, разделив их пробелами. Слова не обязательно писать полностью, поиск должен выводить результаты в которых участвуют все ключевые слова. Выходные поля следующие: ФИО, отдел, должность, адрес. Например, если пользователь вводит ключевые слова «на афа», то результатами могут быть следующие записи: Назаров Зафар Набиев Сафар Афандиев Навруз Насриддин Афанди

блин извиняюсь!

просто здесь есть то что я не смог реализовать!

Поиск должен быть осуществлен по трем полям в этих двух таблицах: ФИО, должность, адрес. Это должен быть умный поиск (smart search), т.е. будет одно поле поиска и можно будет написать несколько ключевых слов, разделив их пробелами. Слова не обязательно писать полностью, поиск должен выводить результаты в которых участвуют все ключевые слова. Выходные поля следующие: ФИО, отдел, должность, адрес.

Поиск должен быть осуществлен по трем полям в этих двух таблицах: ФИО, должность, адрес. Это должен быть умный поиск (smart search), т.е. будет одно поле поиска и можно будет написать несколько ключевых слов, разделив их пробелами. Слова не обязательно писать полностью, поиск должен выводить результаты в которых участвуют все ключевые слова. Выходные поля следующие: ФИО, отдел, должность, адрес.

может кто нить обьяснит мне как это сделать!!??

уже целый день мучаюсь с этим(

есть вариант, нанять программиста

если не нужен нечеткий поиск, до вроде достаточно использовать LIKE

WHERE field LIKE '%string%'

это больше похоже на ilike

если не нужен нечеткий поиск, до вроде достаточно использовать LIKE

то есть только LIKE использовать!?

и триграммный индекс, да

есть в pg и full text search

без регулярных выражений?

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

без

вроде с русским тоже работает

без регулярных выражений?

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

насчет индекса для like/ilike https://stackoverflow.com/a/13452528/5448990

Ребята, есть вопрос по поводу блокировок. Допустим, есть две таблицы: users и gifts. В таблице users есть поле users.gift_id, которое ссылается на gifts.id. Каждый gift знает, сколько максимум userов может на него ссылаться (gifts.max_users_amount) и сколько ссылаются в данный момент времени (gifts.current_users_amount). В бизнес-логике приложения нужно реализовать следующее: выбрать user, выбрать незанятый gift (current_users_amount < max_users_amount), привязать gift к user (users.gift_id = gifts.id) и увеличить счетчик gifts.current_users_amount на 1. Сейчас я вижу такую последовательность: 1. найти незанятый gift 2. привязать его к пользователю 3. увеличить количество пользователей в gift. Но беда в том, что между 1 и 3 кто-то другой уже может захватить этот конкретный gift и тогда 3 шаг выполнить не получится, потому что условие current_users_amount < max_users_amount не выполнится. Разумеется, такая ситуация может возникнуть, когда current_users_amount стремиться к max_users_amount. Теперь вопрос: как предотвратить эту ситуацию? Извлекать gifts с помощью SELECT FOR UPDATE?

просто я сам с mongodb работаю а в этой задаче postgresql и началось головоломка! придется читать доки и тратить время на это!

а в монге как вы решали эту задачу? там только regexp

Ребята, есть вопрос по поводу блокировок. Допустим, есть две таблицы: users и gifts. В таблице users есть поле users.gift_id, которое ссылается на gifts.id. Каждый gift знает, сколько максимум userов может на него ссылаться (gifts.max_users_amount) и сколько ссылаются в данный момент времени (gifts.current_users_amount). В бизнес-логике приложения нужно реализовать следующее: выбрать user, выбрать незанятый gift (current_users_amount < max_users_amount), привязать gift к user (users.gift_id = gifts.id) и увеличить счетчик gifts.current_users_amount на 1. Сейчас я вижу такую последовательность: 1. найти незанятый gift 2. привязать его к пользователю 3. увеличить количество пользователей в gift. Но беда в том, что между 1 и 3 кто-то другой уже может захватить этот конкретный gift и тогда 3 шаг выполнить не получится, потому что условие current_users_amount < max_users_amount не выполнится. Разумеется, такая ситуация может возникнуть, когда current_users_amount стремиться к max_users_amount. Теперь вопрос: как предотвратить эту ситуацию? Извлекать gifts с помощью SELECT FOR UPDATE?

почитайте, что такое транзакции и зачем они нужны

в монге есть js, им можно сделать очень странные вещи, правда, совершенно ужасной вычислительной сложностью

а в монге как вы решали эту задачу? там только regexp

да вот и спрашиваю . .с регулярками трудно получается!

в монге есть js, им можно сделать очень странные вещи, правда, совершенно ужасной вычислительной сложностью

нет, это не считается ;)

да вот и спрашиваю . .с регулярками трудно получается!

читайте про FTS

читайте про FTS

подходит для решения задачи!?

более чем

почитайте, что такое транзакции и зачем они нужны

Насколько я понимаю, в данной ситуации нужен Serializable, верно?

можно сразу выдать визитку pgpro, чтобы чинить с gdb, когда умрёт :)

ничего там не сломается

ничего там не сломается

https://habrahabr.ru/company/postgrespro/blog/301238/

Насколько я понимаю, в данной ситуации нужен Serializable, верно?

нет

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

но, это неприятно, долго и неправильно

Всем привет. Есть таблица геоточек с их адрессами. create table address (lat int not null, lon int not null, lang int not null, address text, PRIMARY KEY(lat, lon, lang)); Так как паралельно в таблицу может сыпаться множество инзертов и селектов и вставляемые данные могли быть уже добавлены. 1) весит тригер (старый постгрес 9.3 без on conflict do nothing) create or replace function check_addr_row() returns trigger as $$ declare _exists boolean; begin execute format('select exists (select * from %I.%I where lat=%L and lon=%L and lang=%L)', G_TABLE_SCHEMA, TG_TABLE_NAME, new.lat, new.lon, new.lang) INTO _exists; if not _exists then return new; end if; return null; end $$ language plpgsql; create trigger check_address before insert on address for each row execute procedure check_addr_row(); 2) Так же при вставке запрашивается exclusive lock. begin work; lock table address in exclusive mode; insert into add (lat, lon, lang, address) values ($1, $2, $3, $4)); commit work Тем не менее иногда транзакции отваливаются "duplicate key value violates unique constraint address_pkey", вешая курсор psycopg2 в python Подскажите в чём может быть ошибка? По идеи exclusive lock должен гарантировать, что только одна транзакция будет изменять данные в таблице (то есть инзерты будут последовательны) И если мы вставляем с дублирующийся ключ, то тригер не должен допустить вставку.

прошу прощения за много букв