Data Science. SQL hub
По всем вопросам- @workakkk @itchannels_telegram - 🔥лучшие ит-каналы @ai_machinelearning_big_data - Machine learning @pythonl - Python @pythonlbooks- python книги📚 @datascienceiot - ml книги📚 РКН: https://vk.cc/cIi9vo #VRHSZ
Show more📈 Analytical overview of Telegram channel Data Science. SQL hub
Channel Data Science. SQL hub (@sqlhub) in the Russian language segment is an active participant. Currently, the community unites 35 983 subscribers, ranking 3 614 in the Technologies & Applications category and 17 757 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 35 983 subscribers.
According to the latest data from 05 September, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 94 over the last 30 days and by -6 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 6.31%. Within the first 24 hours after publication, content typically collects 3.35% reactions from the total number of subscribers.
- Post reach: On average, each post receives 2 271 views. Within the first day, a publication typically gains 1 205 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 9.
- Thematic interests: Content is focused on key topics such as sql, индекс, postgres, index, sqlite.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“По всем вопросам- @workakkk
@itchannels_telegram - 🔥лучшие ит-каналы
@ai_machinelearning_big_data - Machine learning
@pythonl - Python
@pythonlbooks- python книги📚
@datascienceiot - ml книги📚
РКН: https://vk.cc/cIi9vo
#VRHSZ”
Thanks to the high frequency of updates (latest data received on 06 September, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
CREATE TABLE t1 (col1 INT, col2 INT INVISIBLE);
INSERT INTO t1 (col1, col2) VALUES(1, 2), (3, 4);
SELECT * FROM t1;
+------+
| col1 |
+------+
| 1 |
| 3 |
+------+
SELECT col1, col2 FROM t1;
+------+------+
| col1 | col2 |
+------+------+
| 1 | 2 |
| 3 | 4 |
+------+------+
https://dev.mysql.com/doc/refman/8.0/en/invisible-columns.html
@sqlhubNumber Item ------------ 202 Book 202 Cartoon 202 Book 207 Book 205 Elephant 207 Elephant 208 Book 209 Biggy 209 Smoke 203 SmokeНужно сгруппировать по
number и вывести уникальные item для него, наподобие:
202 Book Cartoon 207 Book Elephant 205 Elephant 208 Book 209 Biggy Smoke 203 SmokeКак это можно сделать? ▶️В целом ничего сложного, с этим справится вот такой запрос:
SELECT Number,
group_concat (DISTINCT Item separator ' ')
FROM TABLE
GROUP BY Number
@sqlhubpg_profile/pgpro_pwr — собственно, об этом и идёт речь в видео.
Спикер рассказывает об архитектуре, возможностях, особенностях работы и способах применения этих расширений.
⏩Видео будет интересено всем, кто работает с СУБД Postgres — администраторам баз данных, инженерам нагрузочного тестирования и разработчикам приложений, непосредственно взаимодействующих с базами данных Postgres.
Enjoy)
📎 YouTube
📎 Презентация
@sqlhub/contrib/. Во-вторых, pg_proc.dat является удобной точкой входа для изучения внутренностей PostgreSQL. Также файл бывает полезен, когда вы примерно понимаете, какую функцию ищите, но не знаете ее название.
📎 Статья
@sqlhubSELECT *
FROM table
WHERE property IN ('a','b','c')
или вот этот:
SELECT *
FROM table
WHERE property='a' OR property='b' OR property='c'
▶️Если говорить про абстрактный SQL - никакой разницы нет. Есть много способов попросить достать одни и те же данные. Впрочем, с точки зрения читаемости человеком in явно выигрывает из-за компактности.
А если рассматривать конкретные реализации - то различия могут быть. Например, postgresql строит разные планы для IN и OR:
explain select * from bigtable where id = 1 or id = 3 or id=4;
QUERY PLAN
----------------------------------
Bitmap Heap Scan on bigtable (cost=13.34..25.34 rows=3 width=12)
Recheck Cond: ((id = 1) OR (id = 3) OR (id = 4))
-> BitmapOr (cost=13.34..13.34 rows=3 width=0)
-> Bitmap Index Scan on bigtable_pkey (cost=0.00..4.45 rows=1 width=0)
Index Cond: (id = 1)
-> Bitmap Index Scan on bigtable_pkey (cost=0.00..4.45 rows=1 width=0)
Index Cond: (id = 3)
-> Bitmap Index Scan on bigtable_pkey (cost=0.00..4.45 rows=1 width=0)
Index Cond: (id = 4)
explain select * from bigtable where id in (1,3,4);
QUERY PLAN
----------------------------------
Index Scan using bigtable_pkey on bigtable (cost=0.44..17.37 rows=3 width=12)
Index Cond: (id = ANY ('{1,3,4}'::integer[]))
Как можно заметить, IN был переписан в другую форму и оценён дешевле, чем несколько эквивалентных OR.
Какие-то другие СУБД может быть переписывают оба запроса в идентичное представление, или же переписывают IN в группу OR. Вопросы производительности необходимо рассматривать только в рамках какой-то конкретной реализации.
Вот такие дела
@sqlhubdev/test/prod) и даже на пустой БД, где нет данных (бэкап структуры без данных)
⏩затраты ресурсов зависят только от количества объектов в БД и количества проверок, а не от объема данных или качества приближения тестовых данных и запросов к реальным
⏩статический анализ может быть встроен в CI как элемент повышения качества разработки
Встраивать такого рода проверки в CI — это однозначно полезная практика. Разовая инвестиция в настройку конвейера исключит спектр потенциальных проблем с расхождением данных.
Подробнее об этом тут:
📎 Статья
@sqlhub