Есть готовые платы-карточки в которых расположены NFC, процессор и есть вывод шины I2C для подключения того же экрана на чернилах чтобы не жрать батарею. Тогда всё это можно уместить максимум в корпус размером с банковскую карточку и толщиной не более 10 мм.
А то сделал супер часы и как в ералаше нужна банка аккумулятора в кармане )) www.youtube.com/watch?v=0nJh6RH3bzw
А мне snap нравиться тем что не нужно гадить в свою систему. Не понравилось взял и удалил без боли.
И ещё с совместимостью библиотек нет проблем.
Использую его в первую очередь для skype (уж очень он глючный и прожорливый если ставить на систему, да ещё и 32 битные либы тащит), zoom и telegram.
Flatpack использую для DBeaver, Steam и Slack.
А из ОС я сидел на Cinnamon, нормально было. Потом попробовав Fedora уже сижу на ней 5 лет.
Насчёт класса не понял. У вас настолько маленькие картинки, что я не знаю что там изображено )
В формате CSV та же информация что и формате по умолчанию.
А читаемость запроса не проблема, есть много онлайн сервисов для форматирования. Думаю алгоритмы не сложные, можно найти в opensource, и создать функция в postgres для вывода запроса в pretty.
Я не понял в каком формате у вас логи postgres? Если я правильно понял, то по умолчанию.
Но если настроить на CSV, то можно грузить в БД напрямую через COPY. И там уже делать что хочешь, фильтровать по времени, длительности, типу, ip адресу клиента и.т.п, смотря что в форматной строке написать.
У меня док — Dell WD15 и ноут Dell Latitude 7490. OS Fedora-32
На офф. сайте написано что они совместимы, но видимо нормально работают только на винде (не пробовал). На доке не работает HDMI, DP не пробовал, нет пока кабеля. Причём ноут видит что монитор подключен через док, но экран чёрный.
/* Схема, таблица, её размер в байтах */
WITH usertables AS
(SELECT nspname AS schemaname,
relname AS tablename,
pg_relation_size(C.oid) AS bytes
FROM pg_class C
LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
WHERE C.relkind = 'r' /* r - "обычная" таблица */
AND C.relhasindex = TRUE /* у которой есть индексы */
AND nspname NOT IN ('pg_catalog',
'information_schema')/* не системная */ ),
/*Схема, таблица, название индекса, его размер в байтах */
userindexes AS
(SELECT schemaname,
tablename,
indexname,
pg_relation_size(C.oid) AS bytes
FROM pg_indexes I
INNER JOIN pg_class C ON I.indexname = C.relname
WHERE schemaname NOT IN ('pg_catalog',
'information_schema') )
SELECT schemaname,
tablename,
pg_size_pretty(S.bytes) AS table_size,
index_count,
pg_size_pretty(sum_bytes) AS sum_index_size,
round((sum_bytes / bytes)::numeric, 1) AS ratio /* коэффициент, на который общий объем всех индексов таблицы, отличается от её объема*/
FROM
(SELECT T.schemaname,
T.tablename,
T.bytes, /* размер таблицы */ count(I.indexname) AS index_count, /* кол-во индексов в таблице */ sum(I.bytes) AS sum_bytes /* их суммарный размер */
FROM usertables T
INNER JOIN userindexes I ON (T.schemaname = I.schemaname
AND T.tablename = I.tablename)
WHERE T.bytes > 10000000 /* желательный размер таблицы в байтах */ AND
I.bytes > 0 /* исключаем таблицы и индексы с размером 0 */
GROUP BY T.schemaname,
T.tablename,
T.bytes) S
WHERE (sum_bytes / bytes) > 2 /* желаемое значение коэффициента */
AND S.schemaname !~ 'temp' /* исключение схем */)
ORDER BY 6 DESC;
Там ограничения размера перенесены внутрь запроса списка БД
Но в место него лучше этот
WITH
btree_index_atts AS (
SELECT
pg_namespace.nspname,
indexclass.relname AS index_name,
indexclass.reltuples,
indexclass.relpages,
pg_index.indrelid,
pg_index.indexrelid,
indexclass.relam,
tableclass.relname AS tablename,
(regexp_split_to_table((pg_index.indkey) :: TEXT, ' ' :: TEXT)) :: SMALLINT AS attnum,
pg_index.indexrelid AS index_oid
FROM ((((pg_index
JOIN pg_class indexclass ON ((pg_index.indexrelid = indexclass.oid)))
JOIN pg_class tableclass ON ((pg_index.indrelid = tableclass.oid)))
JOIN pg_namespace ON ((pg_namespace.oid = indexclass.relnamespace)))
JOIN pg_am ON ((indexclass.relam = pg_am.oid)))
WHERE ((pg_am.amname = 'btree' :: NAME) AND (indexclass.relpages > 0))
),
index_item_sizes AS (
SELECT
ind_atts.nspname,
ind_atts.index_name,
ind_atts.reltuples,
ind_atts.relpages,
ind_atts.relam,
ind_atts.indrelid AS table_oid,
ind_atts.index_oid,
(current_setting('block_size' :: TEXT)) :: NUMERIC AS bs,
8 AS maxalign,
24 AS pagehdr,
CASE
WHEN (max(COALESCE(pg_stats.null_frac, (0) :: REAL)) = (0) :: DOUBLE PRECISION)
THEN 2
ELSE 6
END AS index_tuple_hdr,
sum((((1) :: DOUBLE PRECISION - COALESCE(pg_stats.null_frac, (0) :: REAL)) *
(COALESCE(pg_stats.avg_width, 1024)) :: DOUBLE PRECISION)) AS nulldatawidth
FROM ((pg_attribute
JOIN btree_index_atts ind_atts
ON (((pg_attribute.attrelid = ind_atts.indexrelid) AND (pg_attribute.attnum = ind_atts.attnum))))
JOIN pg_stats ON (((pg_stats.schemaname = ind_atts.nspname) AND (((pg_stats.tablename = ind_atts.tablename) AND
((pg_stats.attname) :: TEXT =
pg_get_indexdef(pg_attribute.attrelid,
(pg_attribute.attnum) :: INTEGER,
TRUE))) OR
((pg_stats.tablename = ind_atts.index_name) AND
(pg_stats.attname = pg_attribute.attname))))))
WHERE (pg_attribute.attnum > 0)
GROUP BY ind_atts.nspname, ind_atts.index_name, ind_atts.reltuples, ind_atts.relpages, ind_atts.relam,
ind_atts.indrelid, ind_atts.index_oid, (current_setting('block_size' :: TEXT)) :: NUMERIC, 8 :: INTEGER
),
index_aligned_est AS (
SELECT
index_item_sizes.maxalign,
index_item_sizes.bs,
index_item_sizes.nspname,
index_item_sizes.index_name,
index_item_sizes.reltuples,
index_item_sizes.relpages,
index_item_sizes.relam,
index_item_sizes.table_oid,
index_item_sizes.index_oid,
COALESCE(ceil((((index_item_sizes.reltuples * ((((((((6 + index_item_sizes.maxalign) -
CASE
WHEN ((index_item_sizes.index_tuple_hdr %
index_item_sizes.maxalign) = 0)
THEN index_item_sizes.maxalign
ELSE (index_item_sizes.index_tuple_hdr %
index_item_sizes.maxalign)
END)) :: DOUBLE PRECISION + index_item_sizes.nulldatawidth)
+ (index_item_sizes.maxalign) :: DOUBLE PRECISION) - (
CASE
WHEN (((index_item_sizes.nulldatawidth) :: INTEGER %
index_item_sizes.maxalign) = 0)
THEN index_item_sizes.maxalign
ELSE ((index_item_sizes.nulldatawidth) :: INTEGER %
index_item_sizes.maxalign)
END) :: DOUBLE PRECISION)) :: NUMERIC) :: DOUBLE PRECISION) /
((index_item_sizes.bs - (index_item_sizes.pagehdr) :: NUMERIC)) :: DOUBLE PRECISION) +
(1) :: DOUBLE PRECISION)), (0) :: DOUBLE PRECISION) AS expected
FROM index_item_sizes
),
raw_bloat AS (
SELECT
current_database() AS dbname,
index_aligned_est.nspname,
pg_class.relname AS table_name,
index_aligned_est.index_name,
(index_aligned_est.bs * ((index_aligned_est.relpages) :: BIGINT) :: NUMERIC) AS totalbytes,
index_aligned_est.expected,
CASE
WHEN ((index_aligned_est.relpages) :: DOUBLE PRECISION <= index_aligned_est.expected)
THEN (0) :: NUMERIC
ELSE (index_aligned_est.bs *
((((index_aligned_est.relpages) :: DOUBLE PRECISION - index_aligned_est.expected)) :: BIGINT) :: NUMERIC)
END AS wastedbytes,
CASE
WHEN ((index_aligned_est.relpages) :: DOUBLE PRECISION <= index_aligned_est.expected)
THEN (0) :: NUMERIC
ELSE (((index_aligned_est.bs * ((((index_aligned_est.relpages) :: DOUBLE PRECISION -
index_aligned_est.expected)) :: BIGINT) :: NUMERIC) * (100) :: NUMERIC) /
(index_aligned_est.bs * ((index_aligned_est.relpages) :: BIGINT) :: NUMERIC))
END AS realbloat,
pg_relation_size((index_aligned_est.table_oid) :: REGCLASS) AS table_bytes,
stat.idx_scan AS index_scans
FROM ((index_aligned_est
JOIN pg_class ON ((pg_class.oid = index_aligned_est.table_oid)))
JOIN pg_stat_user_indexes stat ON ((index_aligned_est.index_oid = stat.indexrelid)))
),
format_bloat AS (
SELECT
raw_bloat.dbname AS database_name,
raw_bloat.nspname AS schema_name,
raw_bloat.table_name,
raw_bloat.index_name,
round(
raw_bloat.realbloat) AS bloat_pct,
round((raw_bloat.wastedbytes / (((1024) :: DOUBLE PRECISION ^
(2) :: DOUBLE PRECISION)) :: NUMERIC)) AS bloat_mb,
round((raw_bloat.totalbytes / (((1024) :: DOUBLE PRECISION ^ (2) :: DOUBLE PRECISION)) :: NUMERIC),
3) AS index_mb,
round(
((raw_bloat.table_bytes) :: NUMERIC / (((1024) :: DOUBLE PRECISION ^ (2) :: DOUBLE PRECISION)) :: NUMERIC),
3) AS table_mb,
raw_bloat.index_scans
FROM raw_bloat
/* ограничение на размер таблиц */
WHERE raw_bloat.table_bytes > 10000000
)
SELECT
format_bloat.database_name,
format_bloat.schema_name,
format_bloat.table_name,
format_bloat.index_name,
format_bloat.index_scans,
format_bloat.bloat_pct,
format_bloat.bloat_mb,
format_bloat.index_mb,
format_bloat.table_mb
FROM format_bloat
WHERE
/* ограничение на размер bloat (более 10MB) */
format_bloat.bloat_mb > 10 AND
/* ограничение на процент bloat индекса */
format_bloat.bloat_pct > 10
ORDER BY format_bloat.bloat_mb DESC;
Выдаёт размер bloat индекса и процент по отношению к размеру таблицы.
Index only scan будет использоваться если мы запрашивает только те колонки, по которым создан индекс. А ещё любая сортировка убивает сканирование по индексу, в лучшем случае будет просто index scan.
А аналитику нельзя свести к нескольким полям, там как там нужны данные по многим полям, иногда даже по всем. Postgres хорошая БД, и она хороша в большинстве случаев, не зря же в её пользу отказываются от Oracle. Но есть случаи когда её возможностей не хватает даже используя разные расширения. Поэтому и создали другие БД для работы с большими данными, аналитикой, и так называемой Big Data и Data Science.
А вообще можете генерировать данные для узких таблиц в Postgres, и сравнить с KH по производительности.
Потом напишите статью на хабре )
PG будет быстрее на OLTP нагрузке. PG не аналитическая БД, даже с партициями (кстати если их больше 1000 PG будет сложно их обрабатывать) и brin индексом не поможет на таблицах с млрд. строк и в сотни ГБ, а с таблицами да в 1ТБ PG очень плохо работает, нужно очень тонко настраивать весь кластер и таблицы.
В общем если у вас OLTP нагрузка PG хорош, для OLAP можно использовать только на небольшом кол-ве данных, с млрд. строк и ТБ данных будет плохо.
И кстати, а как вам помогут узкие таблицы? Это такой суррогат для замены широкой колоночной таблицы? )
Число какашек напомнило 6-ю серию 10-го сезона «Доктора Кто» про Extremis.
Истина про эмуляцию компьютером вселенной и потому исключающем случайность в самой эмуляции т.к. компьютер не может создать случайность ))
Согласен. Вообще детские ошибки. А для таких множественных потоков и транзакций нужно использовать пуллер типа pgbouncer, т… к для postgres дорого создавать для каждого соединения отдельный процесс.
Ну вот опять, близиться 3-я мировая за цвета. Можно уже названия придумывать. Цветная Третья Мировая Война — ЦТМВ
И будем внукам говорить — Вот когда была ЦТМВ…
Вроде неплохо звучит.
Тёмные и светлые оттенки зелёного вроде никого не задевают. Жёлтый отнесут к азиатам, красный к коммунистам, фиолетовый и голубой к ЛГБТ. Ну вроде закончились цвета )
А то сделал супер часы и как в ералаше нужна банка аккумулятора в кармане ))
www.youtube.com/watch?v=0nJh6RH3bzw
И ещё с совместимостью библиотек нет проблем.
Использую его в первую очередь для skype (уж очень он глючный и прожорливый если ставить на систему, да ещё и 32 битные либы тащит), zoom и telegram.
Flatpack использую для DBeaver, Steam и Slack.
А из ОС я сидел на Cinnamon, нормально было. Потом попробовав Fedora уже сижу на ней 5 лет.
В формате CSV та же информация что и формате по умолчанию.
А читаемость запроса не проблема, есть много онлайн сервисов для форматирования. Думаю алгоритмы не сложные, можно найти в opensource, и создать функция в postgres для вывода запроса в pretty.
Но если настроить на CSV, то можно грузить в БД напрямую через COPY. И там уже делать что хочешь, фильтровать по времени, длительности, типу, ip адресу клиента и.т.п, смотря что в форматной строке написать.
На офф. сайте написано что они совместимы, но видимо нормально работают только на винде (не пробовал). На доке не работает HDMI, DP не пробовал, нет пока кабеля. Причём ноут видит что монитор подключен через док, но экран чёрный.
Там ограничения размера перенесены внутрь запроса списка БД
Но в место него лучше этот
Выдаёт размер bloat индекса и процент по отношению к размеру таблицы.
А аналитику нельзя свести к нескольким полям, там как там нужны данные по многим полям, иногда даже по всем. Postgres хорошая БД, и она хороша в большинстве случаев, не зря же в её пользу отказываются от Oracle. Но есть случаи когда её возможностей не хватает даже используя разные расширения. Поэтому и создали другие БД для работы с большими данными, аналитикой, и так называемой Big Data и Data Science.
А вообще можете генерировать данные для узких таблиц в Postgres, и сравнить с KH по производительности.
Потом напишите статью на хабре )
В общем если у вас OLTP нагрузка PG хорош, для OLAP можно использовать только на небольшом кол-ве данных, с млрд. строк и ТБ данных будет плохо.
И кстати, а как вам помогут узкие таблицы? Это такой суррогат для замены широкой колоночной таблицы? )
Истина про эмуляцию компьютером вселенной и потому исключающем случайность в самой эмуляции т.к. компьютер не может создать случайность ))
И будем внукам говорить — Вот когда была ЦТМВ…
Вроде неплохо звучит.