эттареализовать асинхронную обработку вставки в таблицу вдоль её сиквенса, с минимум телодвижений и без пропусков. с одним простеньким журналом.
...
Даже если какая-то падла редиска продержит очередное значение неделю, закоммитив сильно задним числом.
...

Если я правильно понимаю,
задача можно сформулировать: "реализовать асинхронный SEQUENCE/SERIAL с возможностью заполнения пропусков"?

Если да, то сценарий реализации в блокировочнике прост:

0. есть таблица с уникальным констрейнтом на id, и признаком "id_reserved bool "

1. сессия в dirty read резервирует себе id по алгоритму:
1) найди минимальный id, у которого id_reserved = false;
2) если нашёл, обнови ему id_reserved = true, при ошибке повтори 1)
3) иначе вставь (id, id_reserved) = (max(id)+1, true), при ошибке повтори 3).

Есть нюанс, таки есть периоды, когда пропуски существуют: между "rollback сесии не с последним id" и "ближайшей попыткой резервирования".
Больше волнует другой вопрос: что за прикладная задача-то такая?

этта
хочу например обновлять статистику по вставкам, но не триггерно, с тормозами на each rows
а джобиком , по очереди, пачечками.

"статистику по вставкам" - это сам факт вставки, не анализируя, что же там вставляется?
Т.е. всего-то видеть, что кто-то зарезервировал запись ("очень вероятно, что я закоммичу запись, и чуть менее вероятно, что её содержимое останется таким как сейчас").
Правильно?

эттаили слайсать очередь сообщений по вставкам , без создание навороченного журналирования "порядка коммитов" или чего иного -- этакого

значение "слайсать" в данном контексте не понял. "слайсать" для чего? прикладной пример можно?

эттаа всего то ведь нужен журнал достигнутого, с одной записью-писью. и возможность only dirty read-а.

с COALESCE (dirty_min-1,commited_max) -- в журнале.
Понял. У вас типа ТОЛЬКО вставка идёт. И хотелось бы не только получить закоммиченное, а ещё и получить данные о незакоммиченных.
Если некую статистику посчитать - (учитывая, что статистика сама по себе "больше чем наглая ложь"), куда ни шло.

А кой вам ещё прок от самих незакомиченных записей, о которых вы узнали в dirty read? Как их "слайсать"? :)

эттаАнатоЛойА кой вам ещё прок от самих незакомиченных записей, о которых вы узнали в dirty read? Как их "слайсать"? :)-- вот под минимальный из них [-1] я очередью отработаю, его [-1] запишу в журнал джоба [как "достигнутого"], и эта единственная запись -- вместо "апдейтить, апдейтить и апдейтить", как вы пердлагаете -- все накладные расходы механизма.

а в следующий раз ломтик для обсчет джобом стартану от журнала, и до текущего "из них[-1]"


дёшево, это было бы, по сравнению с тем, что требуется сейчас.
почему [-1]? У вас один писатель всего?

эттаАнатоЛойпропущено...

почему [-1]? У вас один писатель всего?

авторс COALESCE (dirty_min-1,commited_max) -- в журнале.
чо то оппонент совсем не всасывает
не всасывает, Карл
печалька
всасывает, Клара, но низко-низко.
теперь понял. :)

Как я ещё понял, ONLY DIRTY - это когда в запросе ТОЛЬКО данные незафиксированные транзакцией. така фича имеется в реализации какой-то СУБД? Или dirty_min будем получать как min(dirty_as_all union committed)?

исправился
АнатоЛойИли dirty_min будем получать как min(dirty_as_all MINUS committed)?

этта... статус [dirty|commited] каждой из ....

Хм... Ну, насколько я знаю, для блокировочного IBM Informix Dynamic Server, например, такая задача теоретически разрешима: в таблицах системного каталога сервера есть таблица с блокировками, поэтому INNER JOIN легко даст ONLY DIRTY, а LEFT OUTER + COALESCE() - [dirty|commited]... С производительностью только может не всё ладно случиться, но утверждать с ходу плохого не буду...