Короче пример. (intAutoID, intSenderID, intReceiverID) (1, 1, 2), (2,2,1), (3, 1, 3), (4, 3, 1), (5, 1, 5), (6, 5,1). Из этого дллжно получиться intAutoID 1,3,5. Либо 2, 4, 6.

Парни, а что , такую лабуду PG даёт запускать? Я что-то уже не помню, но мне казалось, что в PG с этим строго.

группировку по рекорду?

SELECT intAutoID AS intLastMessageID FROM ( SELECT intAutoID, COUNT(1), MAX(datSentDate) , intSenderID, intReceiverID, CONCAT(LEAST(intSenderID, intReceiverID), ":", GREATEST(intSenderID, intReceiverID) ) AS roomkey FROM tblmessages WHERE intSenderID != intReceiverID GROUP BY roomkey ORDER BY intSenderID) AS custom;

Вадим, у тебя НЕТ КРИТЕРИЕВ ОТБОРА ЗАПИСЕЙ ВООБЩЕ, как тут можно говорить о какой-то производительности ? Говно запрос, и не будет никогда быстро работать.

ЗАпрос точно правильно работает, я тестил неоднократно

НУ я ж и прошу помощи

группировку по рекорду?

Я в смысле что есть поля, которые ни в агрегатах, ни в GROUP BY

ЗАпрос точно правильно работает, я тестил неоднократно

Он просто неверный. Не может работать.

Что PK перескакивает значения -- это воообще не проблема, и никак не связано с блокировками. Если ты конечно новые ID не сам генерируешь через (select max(id) ...)

ну там как отловили. под двумя пользователями пишется одновременно инфа в таблицу. Стоит блокировка, чтобы одновременно не записывали. В итоге одна запись записывается, вторая отбрасывается и пользователю на фронте пишется что-то типа "повторите позже". Ну это все гуд, так и задумывалось. Однако айдишник перескакивает. т.е по факту запись то одна была, значит айдишник должен увеличится на +1, но он увеличивается на+2, как будто было 2 записи. У нас на эти айдишники завязано много логики, генерация файлов и прочего. соответственно могут получаться ситуации, что из-за того, что в БД посчиталось +2, юзеру отдастся например не его счет за покупку, а счет другого пользователя. как-то так

нужно получить уникальные записи по senderID и receiverID. Одну запись по intAutoID(уникальную). Запрос правильно работает. Но для больших данных очень долго

Вот видишь, ты даже сформулировать не в состоянии, что запрос выдать должен.

ЗАпрос точно правильно работает, я тестил неоднократно

можно накатить условный интекс where senderId > receiverID разделить подзапрос на два, без конката, но с условиями senderId > receiverID и senderId < receiverID соответсвтенно

Спасибо за помощь

SELECT * FROM robjects WHERE MATCH(type) AGAINST ('commercial' IN BOOLEAN MODE) LIMIT 10 Вот так быстро работает SELECT * FROM robjects WHERE MATCH(type) AGAINST ('commercial' IN BOOLEAN MODE) AND ID > 20000 LIMIT 10 Вот так уже на две минуты в зависон уходит. Если ещё один MATCH AGAINST добавить, то вообще трындец.

Ну, значит селективность плохая для критерия. НО в первом запросе это съедается LIMIT -ом, он просто тупо выбрасывает быстро тебе первые 10 записей, что нашлись по полнотекстовому индексу, и всё. Если ты уберёшь LIMIT , скорее всего будет так же хреново, как и во втором запросе.

ну там как отловили. под двумя пользователями пишется одновременно инфа в таблицу. Стоит блокировка, чтобы одновременно не записывали. В итоге одна запись записывается, вторая отбрасывается и пользователю на фронте пишется что-то типа "повторите позже". Ну это все гуд, так и задумывалось. Однако айдишник перескакивает. т.е по факту запись то одна была, значит айдишник должен увеличится на +1, но он увеличивается на+2, как будто было 2 записи. У нас на эти айдишники завязано много логики, генерация файлов и прочего. соответственно могут получаться ситуации, что из-за того, что в БД посчиталось +2, юзеру отдастся например не его счет за покупку, а счет другого пользователя. как-то так

Ох какой ужас. Извините

SELECT * FROM robjects WHERE MATCH(type) AGAINST ('commercial' IN BOOLEAN MODE) LIMIT 10 Вот так быстро работает SELECT * FROM robjects WHERE MATCH(type) AGAINST ('commercial' IN BOOLEAN MODE) AND ID > 20000 LIMIT 10 Вот так уже на две минуты в зависон уходит. Если ещё один MATCH AGAINST добавить, то вообще трындец.

Ну да, это как раз проблема низкой селективности индексов (условий) по отдельности и (может быть) высокой вместе. НО про итоговую селективность ты , видимо , не паришься, поскольку LIMIT используешь.

в каждом подзапросе, сразу сделать группировку, только в первом случае вытаскивать sender as col1, receiver as col2 во втором receiver as col1, sender as col2

и потом уже на схлопывать

ну там как отловили. под двумя пользователями пишется одновременно инфа в таблицу. Стоит блокировка, чтобы одновременно не записывали. В итоге одна запись записывается, вторая отбрасывается и пользователю на фронте пишется что-то типа "повторите позже". Ну это все гуд, так и задумывалось. Однако айдишник перескакивает. т.е по факту запись то одна была, значит айдишник должен увеличится на +1, но он увеличивается на+2, как будто было 2 записи. У нас на эти айдишники завязано много логики, генерация файлов и прочего. соответственно могут получаться ситуации, что из-за того, что в БД посчиталось +2, юзеру отдастся например не его счет за покупку, а счет другого пользователя. как-то так

Надо сначала получать в базе ID и потом работать с ним. В чём тут проблема?

Ну да, это как раз проблема низкой селективности индексов (условий) по отдельности и (может быть) высокой вместе. НО про итоговую селективность ты , видимо , не паришься, поскольку LIMIT используешь.

Да верно всё. Просто юзеру не скажешь, не вводи запросы с плохой селективностью. Наверно, придётся дробить таблицу на несколько, там изначально организация хреновенькая. В type например, такая ерунда Сооружение (Нежилое, Перегон станция "Арбатская" - станция "Александровский сад")

Вы же не получаете я надеюсь ID, например, для файла независимо от базы?

Надо отдельно, получается станции метро делать справочник, наверно, Енам с типами помещений и др.

ну там как отловили. под двумя пользователями пишется одновременно инфа в таблицу. Стоит блокировка, чтобы одновременно не записывали. В итоге одна запись записывается, вторая отбрасывается и пользователю на фронте пишется что-то типа "повторите позже". Ну это все гуд, так и задумывалось. Однако айдишник перескакивает. т.е по факту запись то одна была, значит айдишник должен увеличится на +1, но он увеличивается на+2, как будто было 2 записи. У нас на эти айдишники завязано много логики, генерация файлов и прочего. соответственно могут получаться ситуации, что из-за того, что в БД посчиталось +2, юзеру отдастся например не его счет за покупку, а счет другого пользователя. как-то так

0) зачем запрещать одновременную запись? 1) Проскакивание номеров в PK -- это НЕ ПРОБЛЕМА, это by design.

можно накатить условный интекс where senderId > receiverID разделить подзапрос на два, без конката, но с условиями senderId > receiverID и senderId < receiverID соответсвтенно

У него там ДВА ПОЛЯ, не будет индек работать

0) зачем запрещать одновременную запись? 1) Проскакивание номеров в PK -- это НЕ ПРОБЛЕМА, это by design.

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

Ребята привет! Хочу мейнтененс базе сделать, но для этого надо бы приостановить все коннекты от приложения. Не подскажете как правильнее это сделать?

Запустит на другом порту к примеру

Но лучше само приложение сделать понимающим такой режим

У него там ДВА ПОЛЯ, не будет индек работать

create index idx on table using btree(senderId > receiverID) ? )

Да верно всё. Просто юзеру не скажешь, не вводи запросы с плохой селективностью. Наверно, придётся дробить таблицу на несколько, там изначально организация хреновенькая. В type например, такая ерунда Сооружение (Нежилое, Перегон станция "Арбатская" - станция "Александровский сад")

Скажешь. И говорят. Возми в гугле поищи слово "and" -- а потом расскажи, куда тебя послали...

а если только одну бд?) т.е. просто приостановить коннект одного пользователя к одной базе ?

Запустит на другом порту к примеру

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

а если только одну бд?) т.е. просто приостановить коннект одного пользователя к одной базе ?

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

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

нагуглила REVOKE CONNECT и GRANT CONNECT ) попробую

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

Это не так решается. И не в это время.

create index idx on table using btree(senderId > receiverID) ? )

Пробовал?

Это не так решается. И не в это время.

а как? какие есть решения?

Пробовал?

делать функциональные индексы? да

нагуглила REVOKE CONNECT и GRANT CONNECT ) попробую

Просто опусти БД. Затем забань входной порт в файерволе. Затем подними БД, сделай мейнтененс, сними запрет в файерволе.

делать функциональные индексы? да

Так селективность хреновая будет всё равно.

Так селективность хреновая будет всё равно.

по 30%

а как? какие есть решения?

Чаще всего при подтверждении заказа. Но можно и онлайн, просто это сложнее и так почти никто не делает.

а как? какие есть решения?

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

Так селективность хреновая будет всё равно.

ну ниче чи 30-50% это хреново?)

Просто опусти БД. Затем забань входной порт в файерволе. Затем подними БД, сделай мейнтененс, сними запрет в файерволе.

у меня две ДБ на сервере, одна должна ничего не заметить и не почувствовать)

а как? какие есть решения?

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

тогда ((SenderID > ReceiverID)::int)::bit)

у меня две ДБ на сервере, одна должна ничего не заметить и не почувствовать)

Так порты у каждой свои...

тогда ((SenderID > ReceiverID)::int)::bit)

И чего, увеличил селективность?

ну ниче чи 30-50% это хреново?)

Хреново. ХОрошо -- это когда процент и менее.

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

да не в корзине, а когда они одновременно заказ отправляют одной и той же позиции. у нас там блокировка на это дело уже стоит. не устраивает только то, что айдишник перепрыгивает на +2. а не на +1 при сохранении в БД

Чаще всего при подтверждении заказа. Но можно и онлайн, просто это сложнее и так почти никто не делает.

Именно,

Хреново. ХОрошо -- это когда процент и менее.

Иму надо взять быстро получить все записи у которых R > S и потом наоборот

да не в корзине, а когда они одновременно заказ отправляют одной и той же позиции. у нас там блокировка на это дело уже стоит. не устраивает только то, что айдишник перепрыгивает на +2. а не на +1 при сохранении в БД

Ещё раз, это by design, нормальное поведение

Так порты у каждой свои...

нет, у меня один postgres работающий на порту 5432, и в нем две database) и одна из database должна ничего не почувствовать. вот

нет, у меня один postgres работающий на порту 5432, и в нем две database) и одна из database должна ничего не почувствовать. вот

В pg_hba.conf отключите доступ к БД, которую нужно обслужить,

нет, у меня один postgres работающий на порту 5432, и в нем две database) и одна из database должна ничего не почувствовать. вот

Сори, забыл PG -терминалогию, это же "КЛАСТЕР"...

нет, у меня один postgres работающий на порту 5432, и в нем две database) и одна из database должна ничего не почувствовать. вот

А лучше бы Вы делали 1 database : 1 cluster — куда удобнее, IMHO. А по вопросу — pg_hba.conf, или, наример: ALTER DATABASE <your_database> ALLOW_CONNECTIONS false;

как-то можно внутри триггера проверить, сетилось конкретное поле в update запросе, повлёкшим триггер или нет? if to_jsonb(new) ? 'field_name' then всегда возвращает true, если в конекртно это поле в апдейте не указывать

pgpsql

да не в корзине, а когда они одновременно заказ отправляют одной и той же позиции. у нас там блокировка на это дело уже стоит. не устраивает только то, что айдишник перепрыгивает на +2. а не на +1 при сохранении в БД

Что за id-ник (чего конкретно)? Как он генерируется (покажите код)? Но если Вы завязались на какое-то поведение именно sequence, кроме генерации уникальных значений, у Вас broken design. :(

как-то можно внутри триггера проверить, сетилось конкретное поле в update запросе, повлёкшим триггер или нет? if to_jsonb(new) ? 'field_name' then всегда возвращает true, если в конекртно это поле в апдейте не указывать

вне зависимости от того, изменялось ли значение? вряд ли. а так - IF NEW.field_name != OLD.field_name

SELECT intAutoID AS intLastMessageID FROM ( SELECT intAutoID, COUNT(1), MAX(datSentDate) , intSenderID, intReceiverID, CONCAT(LEAST(intSenderID, intReceiverID), ":", GREATEST(intSenderID, intReceiverID) ) AS roomkey FROM tblmessages WHERE intSenderID != intReceiverID GROUP BY roomkey ORDER BY intSenderID) AS custom;

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

вне зависимости от того, изменялось ли значение? вряд ли. а так - IF NEW.field_name != OLD.field_name

да, они будут равны, если в update-запросе не указать поле ield_name..

вне зависимости от того, изменялось ли значение? вряд ли. а так - IF NEW.field_name != OLD.field_name

Лучше IS DISTINCT FROM, в общем случае.

да, они будут равны, если в update-запросе не указать поле ield_name..

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

Лучше IS DISTINCT FROM, в общем случае.

не знал, спасибо

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

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

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

А зачем? Может быть, Вам хватит просто (при создании триггера): UPDATE [ OF column_name [, ... ] ]

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

Тогда они равны будут , старое и новое.

А зачем? Может быть, Вам хватит просто (при создании триггера): UPDATE [ OF column_name [, ... ] ]

а, можно триггер сделать на апдейт конкретного поля?

а, можно триггер сделать на апдейт конкретного поля?

Да, или полей — column_name [, ... ]

Да, или полей — column_name [, ... ]

спасибо. это, кажется, то, что нужно

спасибо. это, кажется, то, что нужно

Но предупреждаю, "UPDATE OF x" проверяет именно и только то, что в UPDATE statement было: UPDATE ... SET <x = ...>, больше ничего. Т.е.: 1. Он сработает при "SET x = x". 2. Поле может измениться без вызова этого триггера (если кто-то его в (другом) before trigger поменяет, например).

Но предупреждаю, "UPDATE OF x" проверяет именно и только то, что в UPDATE statement было: UPDATE ... SET <x = ...>, больше ничего. Т.е.: 1. Он сработает при "SET x = x". 2. Поле может измениться без вызова этого триггера (если кто-то его в (другом) before trigger поменяет, например).

да, это понятно. спасибо

А лучше бы Вы делали 1 database : 1 cluster — куда удобнее, IMHO. А по вопросу — pg_hba.conf, или, наример: ALTER DATABASE <your_database> ALLOW_CONNECTIONS false;

ALTER DATABASE.. клево! спасибо) если полностью к базе коннект закрывать, очень удобно!! Я правда сделала через revoke connect on DATABASE <dbname> from <username>; Этот случай, получается, если закрывать надо для конкретного пользователя) обе заметки добавила в меморис) всем спасибо еще раз) ☺️ После обслуживания базе правда легче не стало, но это уже совсем другая история ?

А лучше бы Вы делали 1 database : 1 cluster — куда удобнее, IMHO. А по вопросу — pg_hba.conf, или, наример: ALTER DATABASE <your_database> ALLOW_CONNECTIONS false;

Век живи, век учись, все равно найдётся более умный. :) По поводу же 1 клястер - 1 БД есть много мнений. Но когда бд весит очень немного, то поднимать для каждой свой клястер весьма накладно.

Век живи, век учись, все равно найдётся более умный. :) По поводу же 1 клястер - 1 БД есть много мнений. Но когда бд весит очень немного, то поднимать для каждой свой клястер весьма накладно.

Да, накладно. Я только об удобстве.

В чем накладность? Там вроде оверхед небольшой

В чем накладность? Там вроде оверхед небольшой

Вот в нём. Я помню, кто-то рассказывал о тысячах (десятках тысяч?) баз / кластеров (что-то типа shared hosting (автоматически создаваемых под каждого клиента)). Суть в том, что им было очень неудобно с кластерами. ;)

В чем накладность? Там вроде оверхед небольшой

У вас сотни баз от 500 Мб до 2ГБ (мне за 9 лет в вебе не попадалось проектов, чтобы на один проект была одна база, всегда несколько). Для каждой разворачивать свою отказоустойчивую конфигурацию? Не жирно ли будет?

У вас сотни баз от 500 Мб до 2ГБ (мне за 9 лет в вебе не попадалось проектов, чтобы на один проект была одна база, всегда несколько). Для каждой разворачивать свою отказоустойчивую конфигурацию? Не жирно ли будет?

Мне попадалась многотеррабайтные базы, и они были одни

Только кластер. Я не понимаю что такое "в проекте много баз по несколько гигов"

Только кластер. Я не понимаю что такое "в проекте много баз по несколько гигов"

Ну вот тот случай, про который я писал выше. Т.е. проект — это database hosting для клиентов.

@BoggArtist будет жить. Поприветствуем!

У вас сотни баз от 500 Мб до 2ГБ (мне за 9 лет в вебе не попадалось проектов, чтобы на один проект была одна база, всегда несколько). Для каждой разворачивать свою отказоустойчивую конфигурацию? Не жирно ли будет?

Им портов то хватит при таком подходе?..)

Короче не мой юзкейс конечно. Вы тут про сервисы, а я тут почти случайно?

Всем привет. :) Я Евгений из SoftServe. У нас в Днепре открылась вакансия для Интермид+ Data Base Developer на один из наших проектов: About Project: Our Client delivers market-leading software solutions that dramatically improve visibility into the performance of converged UC networks. Our flagship offering Management Platform improves service delivery across integrated voice, data, video, and application solutions by providing critical performance information while also allowing you to manage, monitor and pro-actively troubleshoot your converged networks. Responsibilities: Database objects creation (table, view, functions) Writing query (SQL, PSQL) Query optimization and troubleshooting Test data generation Deployment scripts preparation Requirements: Good experience in any SQL database Good experience in NoSQL databases (Redis, MongoDB, etc.) Knowledge in DWH creation processes Self-motivated and self-organized team member Spoken English level – Intermediate and above As a Plus: Citus, Postgres native partitioning ETL and logging process Any experience in Logi Experience in programming for Kafka Some BI tool Technology Stack: PostgreSQL MS SQL Server, Kafka Logi FlyWay, GitLab, Jenkins Openshift Рассматривается тот, у кого есть любая SQL, работать нужно будет с PostgreSQL и с опытом в любой NoSQL, всему что требуется на проекте - дотрейнят. Ищем специалиста в офис в центре Днепра. У нас тепло, светло и прочие приятности от самой крупной компании в Днепре. Английский должен быть более-менее разговорным, есть митинги с клиентом. И зарплатный вопрос, самый важный, ведь правда ? Мы рассчитываем, что это будет от 2к до 2,7. Можно рассматривать и более высокую, все будет зависеть от разных факторов. Так что не стесняйтесь писать, даже если ваши пожелания не вмещаются в вилку ) Можете написать мне сюда (в Телеграм) или отправить всю информацию о себе на почту ysukh@softserveinc.com Жду ваших писем и сообщений ) На всякий случай, вот ссылка на вакансию на нашем сайте - https://career.softserveinc.com/uk-ua/vacancy/14252-db-software-engineer Если есть вопросы - пишите )

Тепло, светло, это понятно, а что с сыростью в центре днепра, это ведь река если я не ошибаюсь?

Тепло, светло, это понятно, а что с сыростью в центре днепра, это ведь река если я не ошибаюсь?

ошибаетесь, это город

Тепло, светло, это понятно, а что с сыростью в центре днепра, это ведь река если я не ошибаюсь?

Ахаха ? Город называется Днепр, точнее Днипро )

Ага уже посмотрел по украински днiпро )

Ахаха ? Город называется Днепр, точнее Днипро )

Да нет, Днепр https://dp.informator.ua/wp-content/uploads/2018/09/40960923_2107235345954883_8992865514355163136_n.jpg

от дотошный :)

Та сам только сегодня прочитал

В общем, подытожим ? SoftServe Dnipro - ждет всех желающих на эту вакансию ?

Всем привет. :) Я Евгений из SoftServe. У нас в Днепре открылась вакансия для Интермид+ Data Base Developer на один из наших проектов: About Project: Our Client delivers market-leading software solutions that dramatically improve visibility into the performance of converged UC networks. Our flagship offering Management Platform improves service delivery across integrated voice, data, video, and application solutions by providing critical performance information while also allowing you to manage, monitor and pro-actively troubleshoot your converged networks. Responsibilities: Database objects creation (table, view, functions) Writing query (SQL, PSQL) Query optimization and troubleshooting Test data generation Deployment scripts preparation Requirements: Good experience in any SQL database Good experience in NoSQL databases (Redis, MongoDB, etc.) Knowledge in DWH creation processes Self-motivated and self-organized team member Spoken English level – Intermediate and above As a Plus: Citus, Postgres native partitioning ETL and logging process Any experience in Logi Experience in programming for Kafka Some BI tool Technology Stack: PostgreSQL MS SQL Server, Kafka Logi FlyWay, GitLab, Jenkins Openshift Рассматривается тот, у кого есть любая SQL, работать нужно будет с PostgreSQL и с опытом в любой NoSQL, всему что требуется на проекте - дотрейнят. Ищем специалиста в офис в центре Днепра. У нас тепло, светло и прочие приятности от самой крупной компании в Днепре. Английский должен быть более-менее разговорным, есть митинги с клиентом. И зарплатный вопрос, самый важный, ведь правда ? Мы рассчитываем, что это будет от 2к до 2,7. Можно рассматривать и более высокую, все будет зависеть от разных факторов. Так что не стесняйтесь писать, даже если ваши пожелания не вмещаются в вилку ) Можете написать мне сюда (в Телеграм) или отправить всю информацию о себе на почту ysukh@softserveinc.com Жду ваших писем и сообщений ) На всякий случай, вот ссылка на вакансию на нашем сайте - https://career.softserveinc.com/uk-ua/vacancy/14252-db-software-engineer Если есть вопросы - пишите )

Вы бы сразу писали, есть вообще вариант удалёнки или нет... > Мы рассчитываем, что это будет от 2к до 2,7 Ну-ну. А потом говорят "ах, специалистов не найдёшь!". ;) > Writing query (SQL, PSQL) (Въедливо) Один запрос надо будет написать? ;)

Вы бы сразу писали, есть вообще вариант удалёнки или нет... > Мы рассчитываем, что это будет от 2к до 2,7 Ну-ну. А потом говорят "ах, специалистов не найдёшь!". ;) > Writing query (SQL, PSQL) (Въедливо) Один запрос надо будет написать? ;)

Вариант удаленки пока не рассматривают, хочется, чтоб был в офисе. Я ж и говорю, есть идеальная вилка от РМа, но мы рассмотрим все варианты) По Кверям: от одного до необходимого количества ?