Всем привет!

Привет

Парни

вопрос

есть Варшава и Минск

координаты

52.2296756, 21.0122287 53.90453979999999,27.5615244

пытаюсь расстояние прямое посчитать

select ST_Distance(ST_SetSRID(ST_MakePoint(21.0122287,52.2296756), 4326), ST_SetSRID(ST_MakePoint(27.5615244,53.90453979999999), 4326))

возвращает 6.76006244456958

дока говорит

For geography type defaults to return minimum geodesic distance between two geographies in meters.

аааа нет, не внимательный я)

Вы могли бы задачу показать — может, Вам бы и так подсказали...

Кстати, что Вам мешает искать ответы на подобные вопросы проверкой на маленьких таблицах в тестовой базе? ;)

спасибо собственно так и сделал

Боюсь задач несколько, и они назойливые) Но я попробую Есть таблица Citizens. У неё есть поля city_id и citizen_name. Надо посчитать количество citi_id, в которых живёт хотя бы один «Иван»

спасибо собственно так и сделал

То есть, Вы и так знаете, как проверять? ;) Тогда не за что. :)

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

When you issue an ALTER TABLE in PostgreSQL it will take an ACCESS EXCLUSIVE lock that blocks everything including SELECT.

Боюсь задач несколько, и они назойливые) Но я попробую Есть таблица Citizens. У неё есть поля city_id и citizen_name. Надо посчитать количество citi_id, в которых живёт хотя бы один «Иван»

SELECT COUNT(DISTINCT city_id) FROM Citizens WHERE citizen_name = 'Иван'; И да, это тривиальные запросы, а не сложные. (Такого уровня Вы и сами достигнете за несколько часов, я думаю.) Попробуйте порешать упражнения / поизучать сопутствующие материалы (тут раньше давали ссылки).

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

Зачем на большой-то? PostgreSQL, естественно, всё равно, большая таблица или маленькая... Я подозреваю, что Вы таки не знаете, как это делается. ;) Рассказать?

SELECT COUNT(DISTINCT city_id) FROM Citizens WHERE citizen_name = 'Иван'; И да, это тривиальные запросы, а не сложные. (Такого уровня Вы и сами достигнете за несколько часов, я думаю.) Попробуйте порешать упражнения / поизучать сопутствующие материалы (тут раньше давали ссылки).

На данном этапе - да. Дальше идёт такой вопрос. Как выдать то, что вы написали, в один запрос с этим? SELECT COUNT(*) AS citizens_count, FROM citizens WHERE country_id = 1 То есть на выходе должна быть таблица с двумя полями - citizens_count, citizens_count_with_ivan

На данном этапе - да. Дальше идёт такой вопрос. Как выдать то, что вы написали, в один запрос с этим? SELECT COUNT(*) AS citizens_count, FROM citizens WHERE country_id = 1 То есть на выходе должна быть таблица с двумя полями - citizens_count, citizens_count_with_ivan

И это тоже просто. ;) В самом деле, поищите упомянутые ссылки (вроде их тут недавно давали) / поработайте над ними.

И это тоже просто. ;) В самом деле, поищите упомянутые ссылки (вроде их тут недавно давали) / поработайте над ними.

Да мне задачу решить надо быстро, поэтому и пошёл на такую крайнюю меру) Так-то обучаться я умею

Зачем на большой-то? PostgreSQL, естественно, всё равно, большая таблица или маленькая... Я подозреваю, что Вы таки не знаете, как это делается. ;) Рассказать?

я исходил из своего примера. У меня большая таблица. Мне надо было оценить сколько займет перевод из int в bigint и будут ли блокировки. Результат печальный. Думаю как ускорить 'alter table change column type'

https://freelansim.ru/tasks/215453

нужны в москву 2 человека

я исходил из своего примера. У меня большая таблица. Мне надо было оценить сколько займет перевод из int в bigint и будут ли блокировки. Результат печальный. Думаю как ускорить 'alter table change column type'

Да врядли Вы его ускорите как таковой. :( У Вас, наверное, это поле PK, и FK на него есть, а то и VIEWs?

Да врядли Вы его ускорите как таковой. :( У Вас, наверное, это поле PK, и FK на него есть, а то и VIEWs?

нет, нету ни pk, ни fk ). Нет связанностей вообще между таблицами. Все вяжется на уровне приложения используюется ORM (ruby). View тоже нет)

нет, нету ни pk, ни fk ). Нет связанностей вообще между таблицами. Все вяжется на уровне приложения используюется ORM (ruby). View тоже нет)

Хмм... Ну так это несколько легче. Можете попробовать что-то в таком духе: 1. ALTER TABLE your_table ADD COLUMN new_id bigint; -- это быстро 2. Затем UPDATE your_table SET new_id = old_id [WHERE какая-то порция]. Можно чередовать с VACUUM (потому что иначе таблица в худшем случае удвоит свой размер). 3. Когда всё приведено в соответствие : BEGIN TRANSACTION; ALTER TABLE ... DROP column new_id; ALTER TABLE ... RENAME new_id TO old_id; COMMIT; Примерно так.

Ярослав, спасибо, подумаю. Еще нашел такой вариант. Может кому будет полезно https://jilt.com/blog/migrations-zero-downtime-rails/

Ярослав, спасибо, подумаю. Еще нашел такой вариант. Может кому будет полезно https://jilt.com/blog/migrations-zero-downtime-rails/

(Пролистал) Да это с виду то же самое, только + аналог INSERT-триггера, который тоже заполняет new_id после своего добавления. Можно и такой повесить, да (между первым и вторым шагом в моём описании). Если новых записей добавляется много, то это может быть выгодно.

(Пролистал) Да это с виду то же самое, только + аналог INSERT-триггера, который тоже заполняет new_id после своего добавления. Можно и такой повесить, да (между первым и вторым шагом в моём описании). Если новых записей добавляется много, то это может быть выгодно.

добавляется) много))

> В MSSQL под такие нужды создаётся процедура, внутри которой будет цикл по строкам, преобразование каждой строки, сверка и запись в таблицу "b" (Даже) в MS SQL такой подход называется RBAR, и за него Вам должно было бы быть стыдно. ;) Лучше всего сделать это запросом. Можете завернуть его в функцию, и запускать её когда и как хотите.

на функциях в сиквеле почему-то просадки постоянно наблюдаются. и да, а применял пару раз подход который оказывается называется RBAR, и мне не стыдно ) иначе выборка из нескольких связанных таблиц получалась очень большой, а условия фильтрации применялись в самом конце. короче через курсоры оказалось и быстрее и для памяти совсем не затратно. но конечно читать такой размазанный алгоритм труднее

на функциях в сиквеле почему-то просадки постоянно наблюдаются. и да, а применял пару раз подход который оказывается называется RBAR, и мне не стыдно ) иначе выборка из нескольких связанных таблиц получалась очень большой, а условия фильтрации применялись в самом конце. короче через курсоры оказалось и быстрее и для памяти совсем не затратно. но конечно читать такой размазанный алгоритм труднее

Бывает всякое, конечно... но у меня по этому поводу есть два соображения: 1. You experience may have expired (т.е. если Вы это делали например, в 2000 году... с тех пор базы данных стали куда получше). 2. Вы всё же могли делать что-то не так или это можно было решить оптимизацией запросов.

3. структура наших таблиц оказалась не пригодна для решения подобной задачи

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

> и да, а применял пару раз подход который оказывается называется RBAR, и мне не стыдно И да, я тоже применял, бывало. ;) Но для некоторых задач тогда лучше ничего и не было. :(

См. HAVING (и подзапросы). Ну или ORDER BY + LIMIT (ну или стандартные FETCH / OFFSET). Зависит от...

См. HAVING (и подзапросы). Ну или ORDER BY + LIMIT (ну или стандартные FETCH / OFFSET). Зависит от...

Решил с помощью MAX и JOIN с GROUB_BY. Спасибо!

Решил с помощью MAX и JOIN с GROUB_BY. Спасибо!

А покажите запрос, мало ли... а то я думаю, при чём тут JOIN. ;)

А покажите запрос, мало ли... а то я думаю, при чём тут JOIN. ;)

Очень плохо?

во подзапросе не хватает id в select-е

или это не пг )

во подзапросе не хватает id в select-е

Вы правы

во подзапросе не хватает id в select-е

Но это демонстрационный запрос скорее) Кто-нибудь может сказать, как концепция это нормально? Просто мне не очень нравится такое решение

можно записать по-другому (CTE) и тогда будет выглядеть чуток получше. но тоже на любителя. а концепция вполне себе

промежуток незачем смотреть ?

Но это демонстрационный запрос скорее) Кто-нибудь может сказать, как концепция это нормально? Просто мне не очень нравится такое решение

А я прямо затормозил (про id в подзапросе). :) Другой вариант: SELECT COUNT(*), MAX(x.amount) FROM (SELECT t.id, SUM(t.amount) AS amount FROM orders AS t GROUP BY t.id) AS x <реплика в сторону> Вообще, кто так таблицы называет? Нет бы order_lines или т.п.

промежуток незачем смотреть ?

Хоть я этого по факту и не вижу, но знаю, что так) Перфекционизм губит

Хоть я этого по факту и не вижу, но знаю, что так) Перфекционизм губит

Общий совет — собирайте и отлаживайте запросы "по шагам".

Очень плохо?

еще я бы для SUM(amount) назначил альяс. потому что явное лучше неявного у Ярослава в https://t.me/pgsql/100157 как раз с таким ?

А я прямо затормозил (про id в подзапросе). :) Другой вариант: SELECT COUNT(*), MAX(x.amount) FROM (SELECT t.id, SUM(t.amount) AS amount FROM orders AS t GROUP BY t.id) AS x <реплика в сторону> Вообще, кто так таблицы называет? Нет бы order_lines или т.п.

Я правильно понимаю, что COUNT(*) в вашем варианте вернёт 2, а не 3? <реплика в сторону> названия таблиц тоже демонстрационные, для упрощения. Реальная задача намного более сложная, и названия таблиц там продуманные, я просто пытаюсь упростить до базовых концепций, что бы не утруждать вас)

> Я правильно понимаю, что COUNT(*) в вашем варианте вернёт 2, а не 3? Отчего бы Вам не попробовать? Всё равно учитесь. ;) > я просто пытаюсь упростить до базовых концепций, что бы не утруждать вас Да такие названия запутывают, IMHO. Я ожидаю, что orders — это таблица заказов, и id в ней — PRIMARY KEY.

> Я правильно понимаю, что COUNT(*) в вашем варианте вернёт 2, а не 3? Отчего бы Вам не попробовать? Всё равно учитесь. ;) > я просто пытаюсь упростить до базовых концепций, что бы не утруждать вас Да такие названия запутывают, IMHO. Я ожидаю, что orders — это таблица заказов, и id в ней — PRIMARY KEY.

Я попробовал ? Моё предположение оправдалось. Получается, что такой вариант не подходит как решение, результат другой выдаёт. Можно как-нибудь более красиво решить это, чем мой изначальный вариант? Меня просто реально коробит из-за того, что в промежуточном результате дублируется сумма для каждого id Извиняюсь за не очевидные именования столбцов для примеров. Сложно продумать хорошую структуру для демо

> Получается, что такой вариант не подходит как решение, результат другой выдаёт. Стоп, решение для чего, конкретно? Что должно считаться? Строки в "orders"? > Извиняюсь за не очевидные именования столбцов для примеров. Сложно продумать хорошую структуру для демо Почему Вы не тренируетесь на готовых обучающих базах и задачах? Хоть бы это придумывать не пришлось...

> Получается, что такой вариант не подходит как решение, результат другой выдаёт. Стоп, решение для чего, конкретно? Что должно считаться? Строки в "orders"? > Извиняюсь за не очевидные именования столбцов для примеров. Сложно продумать хорошую структуру для демо Почему Вы не тренируетесь на готовых обучающих базах и задачах? Хоть бы это придумывать не пришлось...

Тот запрос, который я написал выдаёт результат, удовлетворяющий требованиям. Единственное, что мне не нравится - как именно под капотом он это делает. Я не тренируюсь сейчас, я решаю конкретную задачу по проекту)

> Тот запрос, который я написал выдаёт результат, удовлетворяющий требованиям Ну так каковы конкретно эти требования? ;) > Я не тренируюсь сейчас, я решаю конкретную задачу по проекту Эх... в SQL без базовых знаний легко "дорешаться" т.е. понаписать запросов, которые с виду работают. :(

> Тот запрос, который я написал выдаёт результат, удовлетворяющий требованиям Ну так каковы конкретно эти требования? ;) > Я не тренируюсь сейчас, я решаю конкретную задачу по проекту Эх... в SQL без базовых знаний легко "дорешаться" т.е. понаписать запросов, которые с виду работают. :(

Требования очень объёмные, я поэтому их утрирую, потому что они project-specific. > Эх... в SQL без базовых знаний легко "дорешаться" т.е. понаписать запросов, которые с виду работают. ? Ну, базовые-то знания у меня есть, но я трезво их оцениваю, поэтому и пришёл в эту группу, и мучаю вас вопросами) Я немного модифицирую задачу, что бы вас не смущать именами таблиц и строк. Допустим, это таблица cart. Так вот, надо посчитать в одном запросе общее кол-во записей в ней + максимальную сумму заказа

Требования очень объёмные, я поэтому их утрирую, потому что они project-specific. > Эх... в SQL без базовых знаний легко "дорешаться" т.е. понаписать запросов, которые с виду работают. ? Ну, базовые-то знания у меня есть, но я трезво их оцениваю, поэтому и пришёл в эту группу, и мучаю вас вопросами) Я немного модифицирую задачу, что бы вас не смущать именами таблиц и строк. Допустим, это таблица cart. Так вот, надо посчитать в одном запросе общее кол-во записей в ней + максимальную сумму заказа

Почему бы Вам не выкладывать свои примеры на каком-нибудь из sqlfiddles? Картинки как-то "совсем не то". :( https://dbfiddle.uk/ https://www.db-fiddle.com/ http://sqlfiddle.com

Почему бы Вам не выкладывать свои примеры на каком-нибудь из sqlfiddles? Картинки как-то "совсем не то". :( https://dbfiddle.uk/ https://www.db-fiddle.com/ http://sqlfiddle.com

Вау. Не знал, что такие есть, спасибо!) https://www.db-fiddle.com/f/bniCCPTSwNrZAzrZXtJVnm/0 И да, я понял, в чём был не прав. В моём изначальном запросе COUNT(DISTINCT orders.id). Я дико извиняюсь, my bad, ваш запрос абсолютно идентичен был. На деле, мне нужен output как в этом фидле, но более красиво

Вау. Не знал, что такие есть, спасибо!) https://www.db-fiddle.com/f/bniCCPTSwNrZAzrZXtJVnm/0 И да, я понял, в чём был не прав. В моём изначальном запросе COUNT(DISTINCT orders.id). Я дико извиняюсь, my bad, ваш запрос абсолютно идентичен был. На деле, мне нужен output как в этом фидле, но более красиво

Ну а так, например? https://www.db-fiddle.com/f/bniCCPTSwNrZAzrZXtJVnm/1

Требования очень объёмные, я поэтому их утрирую, потому что они project-specific. > Эх... в SQL без базовых знаний легко "дорешаться" т.е. понаписать запросов, которые с виду работают. ? Ну, базовые-то знания у меня есть, но я трезво их оцениваю, поэтому и пришёл в эту группу, и мучаю вас вопросами) Я немного модифицирую задачу, что бы вас не смущать именами таблиц и строк. Допустим, это таблица cart. Так вот, надо посчитать в одном запросе общее кол-во записей в ней + максимальную сумму заказа

А оконные функции можно использовать?

А оконные функции можно использовать?

Да

Да

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

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

Подскажете, куда копать? Я пробовал, но не нашёл способа, как их применить здесь

Подскажете, куда копать? Я пробовал, но не нашёл способа, как их применить здесь

https://habr.com/post/268983/ это мне как то помогло сделать первый шаг, и ковырять дальше их

Тебе нужно именно кол-во строк или кол-во заказов?

Тебе нужно именно кол-во строк или кол-во заказов?

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

А почему именно в одном запросе?

Ну а так, например? https://www.db-fiddle.com/f/bniCCPTSwNrZAzrZXtJVnm/1

А вы - маэстро) Я бы не додумался, хотя по отдельности всё это знаю. А какие ещё могут быть вариации?

А почему именно в одном запросе?

Потому что есть 1 SQL файл, который должен отдать полную статистику

Ну а так, например? https://www.db-fiddle.com/f/bniCCPTSwNrZAzrZXtJVnm/1

Тогда это верное решение, оконные функции конечно хорошо, но тут они не подойдут, нужно именно группировку использовать

А вы - маэстро) Я бы не додумался, хотя по отдельности всё это знаю. А какие ещё могут быть вариации?

ответ точно 3, 15 правильный? а то у меня сложилось впечатление что на этих данных ожидалось 2, 15, не?

ответ точно 3, 15 правильный? а то у меня сложилось впечатление что на этих данных ожидалось 2, 15, не?

Нет, именно 3, 15

Тогда это верное решение, оконные функции конечно хорошо, но тут они не подойдут, нужно именно группировку использовать

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

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

Правильно! Вот для того же примера: SELECT SUM(item_price) OVER (PARTITION BY order_id) AS order_total, COUNT(*) OVER () AS lines FROM cart ORDER BY order_total DESC LIMIT 1;

(шутка) Но иллюстрирует, да.

Правильно! Вот для того же примера: SELECT SUM(item_price) OVER (PARTITION BY order_id) AS order_total, COUNT(*) OVER () AS lines FROM cart ORDER BY order_total DESC LIMIT 1;

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

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

Так этого и не требовалось — нужен был не заказ с максимальной суммой, а максимальная сумма среди заказов.

Так этого и не требовалось — нужен был не заказ с максимальной суммой, а максимальная сумма среди заказов.

Ну эт моя привычка думать чуть более каверзно)) Не так понял задачу, думал про количество позиций в заказе А так и правда все одинаково будет

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

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

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

А "вектора" это что, какой тип данных?

обычные математические вектора. double/float