Да, я тоже. Но и охотники за золотишком тоже, поэтому там, где они остались целые, взлетели в цене непропорционально росту золота на бирже.
Что касается СИТ, там есть БСИТ и ПСИТ. Именно последние (напр. КП801 - тоже где-то видел в продаже остатки) имеют максмально триодные ВАХ-и. Толковую литературу не видел, но где-то был справочник, поищу.
Из современных самые интересные по ВАХ - это SiC, напр UJ3N065025K3S. Они, конечно, выходят на насыщение, но очень неохотно, долго оставаясь в линейном режиме. Поэтому их можно использовать как твердотельные триоды, напр. добавив местную ООС. Ну и запас прочности по температуре поражает, 175°C нормальная рабочая температура. При температуре, когда расплавится ПОС-60, которым они были припаяны, они ещё не потеряют своих свойств.
Один из самых популярных и всё ещё доступных мощных полевиков с управляющим переходом: КП903А, Ic.нач <= 0.7А (типично 0.5 А), S=85 мА/В. Их, кстати, можно параллелить без ограничений (обычно достаточно 3-5) для получения выходного каскада с "пентодным" семейством характеристик.
Очень интересная концепция. Встречали такой фильтр, реализованный в железе/аналоговой схеме? Если его совместить с flash adc, то должен получиться быстрый и помехоустойчивый захват, не требующий устройства выборки/хранения.
Родной усилитель на радиоле был сделан по классу AB
Судя по карте напряжений, всё-таки в B: между базами выходников только 0.5 В. Звучал поэтому действительно плохо, в тихом режиме нельзя было разобрать детали.
Перекосы в распределении - коварная штука. Не расширяя список значений most_common_vals/_freqs, рискуем потерять часть часть головы распределения, которая не влезла в дефолтные списки. Вам известны проекты, которые более адаптивно собирают статистику, расширяя или сужая при необходимости эти списки значений?
Подскажите, ванильный ALTER TABLE... ALTER [ COLUMN ] имя_столбца SET STATISTICS { integer | DEFAULT } тоже ведь устраняет проблему гранулярного контроля статистикой на уровне столбцов? Кажется, что так. И похоже, что решает более целостно - заботясь только о статистике самого набора данных и не держа в голове возможность изменения default_statistics_target.
Очереди в БД + машина состояний = вполне рабочий паттерн. SELECT FOR UPDATE SKIP LOCKED - достаточно тяжёлый подход. По сравнению с advisory locks.
Если в WHERE условие по одним столбцам по BETWEEN (schedule_time <= ?), а в ORDER BY по другим (priority DESC, COALESCE(delay_tolerance_time, schedule_time)), это не сможет безусловно работать быстро, какой бы индекс ни добавить. Но сможет работать молниеносно, если свести к одним и тем же столбцам, за счёт выборки уже отсортированных значений по единому индексу. Либо же придётся городить переход в промежуточные состояния и использовать частичные индексы по этим состояниям, что тоже неплохо бьёт по скорости.
Часто машину большого количества состояний партицируют по значениям состояний - чтобы более горячие для работы состояния оказывались рядом друг с другом в одной партиции с локальными индексами. Удобства в работе это сильно убавляет, но чего только не сделаешь ради производительности и экономии памяти.
Изоляция нагрузки. Высокая нагрузка на профили не повлияет на производительность финансовых транзакций.
Это должно довольно сильно повезти. В худшем случае придётся держать несколько проекций одних и тех же данных и поддерживать их согласованность.
Потому что разбиение на группы колонок делает невозможным многоколоночные индексы, объединяющие данные из разных групп.
Выбор тут простой. Если вы столкнулись с очень широкими таблицами в БД - проверьте, не появился ли в OLTP-системе филиал OLAP-системы с необходимостью обрабатывать много данных за один запрос. Если да - пора переезжать в колоночную БД. Если же имеет место осознанная денормализация без признаков OLAP - значит надо оставить как есть. Пример такой денормализации - пакетная обработка на основе конечных автоматов.
Использовать медиану, не показав или не понимая распределение данных — это манипуляшки.
Не осгласен в тезисом. Медиана, и все любые прочие процентили - способ узнать функцию (не плотность) распределения. Ну то есть обратную функцию, конечно. И в отдельных лишь точках. Но узнать.
При этом, согласен с автором, что многие пытаются использовать процентили сами не понимая, когда это применимо и когда нет. Например, когда делают выводы о производительности, на основе высоких процентилей (99+) показателя <latency>, при этом нагрзука на сервис очень мала, бакеты для расчёта взяты наобум и рассчитанный высокий процентиль будет крайне неточен.
Всё верно, эффективность HOT Update сопоставима или даже превосходит INSERT. Про fillfactor очень важное замечание, однако на активно работающих системах это не нужно: необходимое пустое место на страницах появляется само.
Скрытый пример с fillfactor
bench=# select pg_stat_statements_reset();
pg_stat_statements_reset
-------------------------------
2025-07-15 23:21:17.508392+03
(1 row)
bench=# create unlogged table tst1 (id bigint, v uuid) with(fillfactor=100);
CREATE TABLE
bench=# create unlogged table tst2 (id bigint, v uuid) with(fillfactor=50);
CREATE TABLE
bench=# insert into tst1(id, v) select id, md5('' || id)::uuid from generate_series(1, 1000000, 1) as id;
INSERT 0 1000000
bench=# insert into tst2(id, v) select id, md5('' || id)::uuid from generate_series(1, 1000000, 1) as id;
INSERT 0 1000000
bench=# create unique index uni_tst1_id on tst1 using btree(id);
CREATE INDEX
bench=# create unique index uni_tst2_id on tst2 using btree(id);
CREATE INDEX
bench=# vacuum tst1;
VACUUM
bench=# vacuum tst2;
VACUUM
bench=# update tst1 set v = md5('' || v)::uuid where id %2 = 0;
UPDATE 500000
bench=# update tst2 set v = md5('' || v)::uuid where id %2 = 0;
UPDATE 500000
bench=# select query, shared_blks_hit + shared_blks_read as shared_blks from pg_stat_statements order by 2 desc;
query | calls | shared_blks | shared_blks_dirtied
-----------------------------------------------------------------------------------------------+-------+-------------+---------------------
update tst1 set v = md5($1 || v)::uuid where id %$2 = $3 | 1 | 3532711 | 14976
update tst2 set v = md5($1 || v)::uuid where id %$2 = $3 | 1 | 1025642 | 7870
insert into tst2(id, v) select id, md5($1 || id)::uuid from generate_series($2, $3, $4) as id | 1 | 1025635 | 12825
insert into tst1(id, v) select id, md5($1 || id)::uuid from generate_series($2, $3, $4) as id | 1 | 1012735 | 6370
create unique index uni_tst2_id on tst2 using btree(id) | 1 | 12928 | 3271
create unique index uni_tst1_id on tst1 using btree(id) | 1 | 6477 | 2313
create unlogged table tst2 (id bigint, v uuid) with(fillfactor=50) | 1 | 92 | 3
create unlogged table tst1 (id bigint, v uuid) with(fillfactor=100) | 1 | 90 | 0
vacuum tst2 | 1 | 58 | 0
vacuum tst1 | 1 | 56 | 0
select pg_stat_statements_reset() | 1 | 0 | 0
(11 rows)
Если снести div верхнего и правого меню, то нагрузка на cpu спадает с 20% до 1.5% в firefox и с 40% до чуть меньше 5% в chrome. При частичном сносе div - частичный эффект.
Да, я тоже. Но и охотники за золотишком тоже, поэтому там, где они остались целые, взлетели в цене непропорционально росту золота на бирже.
Что касается СИТ, там есть БСИТ и ПСИТ. Именно последние (напр. КП801 - тоже где-то видел в продаже остатки) имеют максмально триодные ВАХ-и. Толковую литературу не видел, но где-то был справочник, поищу.
Из современных самые интересные по ВАХ - это SiC, напр UJ3N065025K3S. Они, конечно, выходят на насыщение, но очень неохотно, долго оставаясь в линейном режиме. Поэтому их можно использовать как твердотельные триоды, напр. добавив местную ООС. Ну и запас прочности по температуре поражает, 175°C нормальная рабочая температура. При температуре, когда расплавится ПОС-60, которым они были припаяны, они ещё не потеряют своих свойств.
Очень понравился обзор, большое спасибо.
Один из самых популярных и всё ещё доступных мощных полевиков с управляющим переходом: КП903А, Ic.нач <= 0.7А (типично 0.5 А), S=85 мА/В. Их, кстати, можно параллелить без ограничений (обычно достаточно 3-5) для получения выходного каскада с "пентодным" семейством характеристик.
Очень интересная концепция. Встречали такой фильтр, реализованный в железе/аналоговой схеме? Если его совместить с flash adc, то должен получиться быстрый и помехоустойчивый захват, не требующий устройства выборки/хранения.
Понятно. Но почему? Стоматологи используют во всю, к тому же анестезиолог не нужен.
Судя по карте напряжений, всё-таки в B: между базами выходников только 0.5 В. Звучал поэтому действительно плохо, в тихом режиме нельзя было разобрать детали.
Для целей наркоза применяют газовую смесь с закисью азота?
Подскажите пожалуйста ISBN.978-5-9775-2112-3Перекосы в распределении - коварная штука. Не расширяя список значений most_common_vals/_freqs, рискуем потерять часть часть головы распределения, которая не влезла в дефолтные списки. Вам известны проекты, которые более адаптивно собирают статистику, расширяя или сужая при необходимости эти списки значений?
Спасибо.
Подскажите, ванильный ALTER TABLE... ALTER [ COLUMN ] имя_столбца SET STATISTICS { integer | DEFAULT } тоже ведь устраняет проблему гранулярного контроля статистикой на уровне столбцов? Кажется, что так. И похоже, что решает более целостно - заботясь только о статистике самого набора данных и не держа в голове возможность изменения default_statistics_target.
Моя любимая тема.
Очереди в БД + машина состояний = вполне рабочий паттерн.
SELECT FOR UPDATE SKIP LOCKED - достаточно тяжёлый подход. По сравнению с advisory locks.
Если в WHERE условие по одним столбцам по BETWEEN (schedule_time <= ?), а в ORDER BY по другим (priority DESC, COALESCE(delay_tolerance_time, schedule_time)), это не сможет безусловно работать быстро, какой бы индекс ни добавить. Но сможет работать молниеносно, если свести к одним и тем же столбцам, за счёт выборки уже отсортированных значений по единому индексу. Либо же придётся городить переход в промежуточные состояния и использовать частичные индексы по этим состояниям, что тоже неплохо бьёт по скорости.
Часто машину большого количества состояний партицируют по значениям состояний - чтобы более горячие для работы состояния оказывались рядом друг с другом в одной партиции с локальными индексами. Удобства в работе это сильно убавляет, но чего только не сделаешь ради производительности и экономии памяти.
В чём же их хранить, в другой БД?
Это должно довольно сильно повезти. В худшем случае придётся держать несколько проекций одних и тех же данных и поддерживать их согласованность.
Потому что разбиение на группы колонок делает невозможным многоколоночные индексы, объединяющие данные из разных групп.
Выбор тут простой. Если вы столкнулись с очень широкими таблицами в БД - проверьте, не появился ли в OLTP-системе филиал OLAP-системы с необходимостью обрабатывать много данных за один запрос. Если да - пора переезжать в колоночную БД.
Если же имеет место осознанная денормализация без признаков OLAP - значит надо оставить как есть. Пример такой денормализации - пакетная обработка на основе конечных автоматов.
Подскажите, пожалуйста, если встречали: есть ли такой модуль регулятора напряжения, что выдаёт двуполярное питание?
Вдруг будет интересно: на фото три "твёрдосплавных сверла". Попробуйте предположить, какие подходят для печатных плат, а какие - нет.
Не осгласен в тезисом. Медиана, и все любые прочие процентили - способ узнать функцию (не плотность) распределения. Ну то есть обратную функцию, конечно. И в отдельных лишь точках. Но узнать.
При этом, согласен с автором, что многие пытаются использовать процентили сами не понимая, когда это применимо и когда нет. Например, когда делают выводы о производительности, на основе высоких процентилей (99+) показателя <latency>, при этом нагрзука на сервис очень мала, бакеты для расчёта взяты наобум и рассчитанный высокий процентиль будет крайне неточен.
Если не секрет, какая была очень плохая реклама?
Очень любопытный проект, спасибо. Не хотите пошарить плату, чтобы желающие могли повторять?
Всё верно, эффективность HOT Update сопоставима или даже превосходит INSERT. Про fillfactor очень важное замечание, однако на активно работающих системах это не нужно: необходимое пустое место на страницах появляется само.
Скрытый пример с fillfactor
Если снести div верхнего и правого меню, то нагрузка на cpu спадает с 20% до 1.5% в firefox и с 40% до чуть меньше 5% в chrome. При частичном сносе div - частичный эффект.