Channel
@pizdatascience
On this record: Growth · Engagement · What this channel posts · Posts · Citations · Cite this entry
35,659subscribers
-92 since we began measuring on 7 August 2026
Risers and fallers across the register · movement among entries of 31,623–100,000.
| Telegram ID | -1002308413502 |
|---|---|
| Type | Channel |
| Username | @pizdatascience |
| Created | Between 1 September 2024 and 31 March 2025— estimated from Telegram’s id allocation, not measured. How this range is calculated. |
| First recorded | 7 August 2026 |
| Last confirmed live | 13 August 2026 |
| Measurements held | 7 |
| Confirmed unchanged | 1 time, most recently 13 August 2026 |
| On Telegram | t.me/pizdatascience |
| Measured (UTC) | Subscribers | Change |
|---|---|---|
| 13 Aug 2026, 01:26 | 35,659 | -142 |
| 12 Aug 2026, 02:43 | 35,801 | +2 |
| 11 Aug 2026, 03:48 | 35,799 | +33 |
| 10 Aug 2026, 00:29 | 35,766 | -4 |
| 8 Aug 2026, 23:31 | 35,770 | +24 |
| 7 Aug 2026, 21:42 | 35,746 | -5 |
| 7 Aug 2026, 08:46 | 35,751 | first reading |
15 posts held, back to 13 July 2026 — the reader has not yet reached the start of this channel’s public history, so older posts may sit further back, unread. Read across 17 pagesof Telegram’s post history, 20 posts per page.
ERR is average views per post over the last 30 days divided by subscribers, the definition TGStat uses, so this figure is comparable with the one you will see elsewhere. It falls structurally as a channel grows: a high ERR on a small channel and a low one on a large channel describe reach mathematics, not quality. We publish the figure and the sample it came from and pass no verdict on it.
ER is defined industry-wide as (forwards + reactions + comments) ÷ views— note the denominator is views, not subscribers. Telegram’s public web preview carries views and reactions but not forward or comment counts, so the reaction rate above is the reactions term only and is therefore a floor: the true ER for this channel is higher by an amount we have not measured and will not estimate.
| Window | Rolling 30 days · latest post in window 12 August 2026 |
|---|---|
| Posts held | 15 (13 July 2026 – 12 August 2026) |
| Views total | 75,470 |
| Reactions total | — |
| Forwards / comments | not exposed by the public surface — not measured, not estimated |
| Readings taken | 12 Aug 2026, 20:56 UTC |
Views are a single reading per post, taken at the time above. A post published in the last day or two is still accumulating views, which pulls the 30-day average down slightly. That is a property of the standard definition rather than a fault in it, so we keep the definition rather than “correcting” the number into something nobody can reproduce.
Precision. Telegram publishes view counts on its public widget in short form — 8.12K, 3.7M — so any reading at or above 1,000 reaches us rounded to three significant figures, and only counts below 1,000 are exact. Averages and rates derived from them are shown to the same precision rather than to the unit: a figure like 3,701,250 would assert digits nobody measured.
Reaction counts are published per emoji and rounded the same way, so a total below 1,000 is exact and a larger one is a sum that may carry a rounded component from each emoji above 1,000. Because it is a sum, it does not look rounded — read a large reaction total as three significant figures per contributing emoji rather than as the figure it prints.
Measured directly from 1 video with a duration reading, out of the posts we hold for this channel — not this channel’s whole posting history, only the sample this register has actually read. An exact reading to the second, taken from the post itself rather than from Telegram’s own rounded chrome, so it carries no ≈ mark.
🔥 SQL-совет: `LATERAL` вместо тяжёлого оконного запроса Нужно получить последнюю операцию каждого пользователя? В PostgreSQL можно не ранжировать всю таблицу через ROW_NUMBER(). SELECT u.id, last_order.id, last_order.created_at FROM users AS u LEFT JOIN LATERAL ( SELECT id, created_at FROM orders WHERE user_id = u.id ORDER BY created_at DESC LIMIT 1 ) AS last_order ON true; LATERA…
🔥Редкий и реально продвинутый SQL-совет: используй логарифмы для произведения вероятностей. В SQL удобно считать SUM, AVG, COUNT, но почти никто не думает про PRODUCT. А в аналитике он часто нужен: вероятность цепочки событий, retention funnel, скоринговые модели, reliability, ML-фичи. Проблема: если перемножать много маленьких чисел, например 0.97 * 0.91 * 0.88 * ..., быстро получишь underflow или потерю точности.…
🔥 Constella: локальная память для файлов, заметок и AI-агентов Constella — open-source desktop-приложение, которое индексирует локальные файлы и превращает их в единую базу знаний для поиска и AI-агентов. Данные хранятся на устройстве: LanceDB используется для векторов, SQLite — для метаданных и knowledge graph. Что умеет: ⏺️ индексировать Obsidian, Documents, Downloads и любые выбранные папки; ⏺️ извлекать текст…
❌ Хотите внедрить ИИ в компании? Не начинайте с выбора модели. Иначе есть риск потратить бюджет, а получить красивые, но бесполезные ответы. Причина большинства неудачных AI-проектов — не технологии. Проблема в данных: они разрознены, устарели, хранятся в 1С, CRM, Excel и десятках других систем. На бесплатном вебинаре разберем, как подготовить данные, чтобы корпоративный ИИ действительно помогал бизнесу, а не гене…
🔥Логическая аналитика с LynxDB LynxDB — это легковесная система для анализа логов, работающая в одном бинарном файле без зависимостей. Она использует язык запросов Lynx Flow, позволяющий легко обрабатывать данные в виде конвейера. Основные моменты: ⏺️ Пайплайн-запросы для обработки данных ⏺️ Полнотекстовый поиск и колоночное хранилище ⏺️ Поддержка кластерного режима и материализованных представлений ⏺️ Никакой кон…
🔥 Продвинутый SQL-прием: partial index вместо “универсального” индекса Если в таблице много строк, но запрос почти всегда смотрит только активные записи, не обязательно индексировать всё. Например, есть таблица заказов: SELECT * FROM orders WHERE user_id = 42 AND status = 'active'; Обычный индекс: CREATE INDEX idx_orders_user_status ON orders(user_id, status); Работает, но он хранит данные по всем статуса…
➡️ Используй EXISTS вместо IN на больших таблицах -- медленнее SELECT * FROM orders o WHERE o.user_id IN (SELECT id FROM users WHERE active = true); -- быстрее SELECT * FROM orders o WHERE EXISTS ( SELECT 1 FROM users u WHERE u.id = o.user_id AND u.active = true ); EXISTS останавливается на первом совпадении и не тянет весь подзапрос в память. На больших данных разница может быть кратной. 🫡 Всё про Da…
🔥 США решили отжать open source у китайцев: на сцену выкатили Laguna S 2.1 Стартап Poolside выкатил свою четвёртую версию Laguna S 2.1 — открытую модель для агентного программирования, которая весит аж 118 млрд параметров. В конторе заявляют, что это самая мощная открытая модель Запада: на кодинговых тестах Laguna не отстаёт от моделей, которые крупнее неё в разы, а кое-где даже обходит их. И главное — она запускает…
🔥 Anthropic запустили официальный плагин для поиска уязвимостей Можно отправить Claude Security проверить изменения перед коммитом или просканировать всю репу. Он найдет дыры и предложит, что можно и нужно исправить 🫡 Всё про Data Science 🇷🇺 Читайте нас в MAX
🔥 Апдейты в плагин! Давно мы не слышались: я упёрся в сложные технические проблемы при разработке и на время сделал паузу. Теперь [надеюсь] эти проблемы позади — и новые релизы будут выходить чаще. Что в новой версии: ⏺️Исправлен баг, из-за которого в редких случаях столбики рисовались неправильных размеров. ⏺️Добавлена beta-версия площадной диаграммы. Апдейт должен прилететь в фигму автоматически. А если плагина …
🔥 Рой ИИ-агентов написал аналог SQLite на Rust за несколько часов Cursor провела необычный эксперимент: агентам выдали только официальную документацию SQLite объёмом 835 страниц и поручили с нуля реализовать собственный движок базы данных на Rust. Без интернета, готового исходного кода и дополнительной помощи. Уже через четыре часа получившиеся реализации правильно выполняли 73–85% запросов из скрытого теста. Посл…
🔥 Хитрый SQL-совет: осторожнее с `NOT IN` Кажется, что эти запросы делают одно и то же: SELECT * FROM users WHERE id NOT IN ( SELECT user_id FROM banned_users ); Но если banned_users.user_id содержит хотя бы один NULL, запрос может вернуть ноль строк. Надёжнее использовать NOT EXISTS: SELECT u.* FROM users AS u WHERE NOT EXISTS ( SELECT 1 FROM banned_users AS b WHERE b.user_id = u.id ); Пр…
Showing the 12 most recent of 15 posts we hold for @pizdatascience. View and reaction counts are the latest single reading for each post, not a live figure, and a recent post is still accumulating both. A view count marked ≈ was rounded by Telegram before we ever saw it — t.me prints views in full below 1,000 and to three significant figures above, so ≈1,200,000 means somewhere between 1,150,000 and 1,249,999. Unmarked counts are exact. Text is reproduced from the public post preview and truncated for length.
Citation-graph rank — 975,370 of 1,151,006entries in the measured graph. A weighted position computed from the forward and mention edges below — republished posts weigh more than named mentions — and recomputed periodically, over the whole graph. Published only as this ordinal position, never as a score: a position is a fact, and a score printed beside one channel’s name would read as a verdict this register does not make. The two counts beneath stay separate for the same reason mentions are never summed with forwards anywhere else on this page — a named-by count costs nothing to manufacture. The top 100 by this measure, or how it is computed.
Named by 1 registered channel — every channel on the register whose own posts have named this one, by its current username or any other username it currently holds, merged from two separately captured readings of the same fact so a namer caught by only one of them is not missed and a namer both caught is not counted twice. A username this channel has since dropped is not matched — that handle may belong to someone else now, and crediting today’s namer to yesterday’s owner would misattribute it.
Named by
Channels on the register whose posts name this channel's handle.
A mention is a weaker signal than a forward and is counted separately for that reason — naming a channel is not republishing it, and a handle in a post body is easy to place deliberately. The post counts beside each row below are distinct posts in which the handle appeared, from posts we have read on both sides — the “Named by N registered channels” figure above is a different count, of distinct NAMING CHANNELS rather than posts, and is not the sum of the rows under it.
A live page changes as we take new readings, so a citation should name the measurement it is based on, not just the URL. The line below cites the subscriber count as measured 13 August 2026 — this entry's latest reading, not the date you are reading this.
“Data Science: SQL и Аналитика данных” (@pizdatascience), 35,659 subscribers as measured 13 August 2026. Telegram Register, tgregister.com/channel/pizdatascience.
Full measurement history, CC BY 4.0. Every reading this register holds for this entry, not just the latest one, as a dated, downloadable record: CSV · JSON. Free to use with attribution to tgregister.com. Each file carries its own generation timestamp, which is the figure to cite for exactly when the data was retrieved.