- бинарные между мажорными версиями нельзя
- завтра 13.2 выходит, я бы на неё сразу прыгал
- можно воспользоваться pg_upgrade — есть и в доке, и видео+статьи доступны

мне для 1С на AstraLinux
думаю слишком рискованно)

Раньше как стандартное "практическое" руководство советовали "Mastering Regular Expressions",  Jeffrey E. F. Friedl.
Но про алгоритмы там почти ничего нет, если я правильно помню.

> а на уровне разжёвывания алгоритмов, осуществляющих все эти волшебные lookahead'ы и рекурсивный поиск

А в этом как раз ничего "хитрого" нет — почти всё это (почти во всех движках) всего лишь backtracking c "оптимизациями".

> Так как, насколько я знаю, конкретных реализаций как минимум не меньше, чем языков программирования

Есть сайты (со ссылками и практическим сравнением реализаций), например https://www.regular-expressions.info/ или https://www.rexegg.com/ .

> Предвещая вопросы, гугление не особенно привело к успеху

Наверное, потому, что "основа" (настоящие регулярные выражения / языки, NFA, DFA, алгоритмы и теоремы) —  это совсем уж "классика" (и почти все движки её, как ни странно, не используют ;) ). По идее, описано в любой книге про parsing, например в Dragon Book.

> А то создаётся впечатление, что регулярки — это какой-то чёрный ящик.

Да ничего "волшебного", на самом деле, в большинстве движков нет.

> Я надеялся, что есть более простые варианты.

А вот в PostgreSQL-овский движок я Вам лезть очень не советую — это уникальная (и очень сложная) реализация, резко отличающаяся от всех привычных (описанных выше), на уровне подхода.
Т.е. понимания того, как работает движок Python, например, она Вам не даст. ;)

> NFA, DFA, алгоритмы и теоремы

README в regex/ постгреса отсылает к учебникам за первый курс по CS

Ну да, это традиционно в курсах про компиляторы изучается (что логично), если я правильно помню.

Тайно надеялся, что вы отреагируете, не разочарован)

> Но про алгоритмы там почти ничего нет, если я правильно помню.
Вот как раз алгоритмы, как происходит поиск совпадений Джеффри Фридл весьма обстоятельно разжёвывал. Причем на примерах НКА, ДКА и POSIX. После внимательного изучения материала становится ясной хохма:
- у нас была одна проблема, мы попытались решить её регулярными выражениями, таперича у нас две проблемы.

коллеги надо совет бывалых
нужен
ETL Tool(set) for MySQL (and some other?) -> PostgreSQL (FOSS есссно)
пожелания - максимально близкий к Microsoft SSIS (ага, с GUI "большинство процедур настроить мышькой" но чтобы и закодить чет сложное норм), ЯП - Python
раниться будет на Windows Server есличто

(Transformation step может быть прям очень сложный со множеством запросов-проверок-подстановок и т.д.)

Да нет там практически ничего (сейчас пролистал третье издание), я правильно вижу?

Более того, там написано:

The two basic technologies behind regular-expression engines have the somewhat imposing names Nondeterministic Finite Automaton (NFA) and Deterministic Finite Automaton (DFA). With mouthfuls like this, you see why I stick to just “NFA” and “DFA”. We won’t be seeing these phrases spelled out again.  I suppose I could explain the underlying theory that goes into these names, if I only knew it! As I hinted, the word deterministic is pretty important, but for the most part the theory is not relevant, so long as we understand the practical effects.

И, опять-таки, к тому, как происходит поиск совпадений в RE engine PostgreSQL, весь этот примитив не относится. ;)

Добрый день!
Версия PostgreSQL 9.6
Есть табличка:

-[ RECORD 4 ]+---------------
databasename | zabbix
schemaname   | public
tablename    | history
can_estimate | t
est_rows     | 3093980000
t_pct_bloat  | 48
table_bloat  | 140917.41
table_mb     | 294726.766
index_name   | history_1
i_bloat_pct  | 75
index_bloat  | 253000
index_mb     | 336219.516

Пытаюсь ее сжать с помощью pgcompact (pgtoolkit), но процесс не зачищает таблицу ( с другими таблицами отработал штатно):

NOTICE Processing results: 37725024 pages left (80778176 pages including toasts and indexes), size reduced by 0 bytes (-24 kB including toasts and indexes) in total, approximately 51.85% (19559540 pages) that is 149 GB more were expected to be compacted after this attempt.
WARNING Processing incomplete: 1 tables left.
NOTICE Processing results: size reduced by 0 bytes (-24 kB including toasts and indexes) in total.
NOTICE Retrying to process, attempt: 2 from 10, 1 databases left.
INFO Vacuum initial: 37725024 pages left, duration 414.033 seconds.
NOTICE Statistics: 37725024 pages (80778176 pages including toasts and indexes), approximately 51.85% (19558898 pages) can be compacted reducing the size by 149 GB.

VACUUM FULL запустить не получится ( нет места )

Стоит ли ждать следующих попыток очистки или искать другое решение?

У меня русский перевод 1-го и 3-го изданий. В третьем - гл. 4. Механика обработки регулярных выражений. Это как я понимаю вопрос об алгоритмах.

И как раз про алгоритмы там на самом деле практически ничего нет.
Цитата как раз из четвёртой главы.
Т.е. он в самом деле пользуется принципом "я знаю regular languages, NFA, DFA, backtracking и много других страшных слов". ;)
Зато в плане практического использования regexp engines книга, говорят, хорошая.

> Зато в плане практического использования regexp engines книга, говорят, хорошая.
Я ж говорю, при наличии мозгов после изучения материала регулярки не вот уж хочется совать везде и всюду. :)

ЗЫ. Слово "практического" тоже выделил, потому что вот.

-[ RECORD 4 ]+---------------
databasename | zabbix
schemaname   | public
tablename    | history
can_estimate | t
est_rows     | 3093980000
t_pct_bloat  | 48
table_bloat  | 140917.41
table_mb     | 294726.766
index_name   | history_1
i_bloat_pct  | 75
index_bloat  | 253000
index_mb     | 336219.516

NOTICE Processing results: 37725024 pages left (80778176 pages including toasts and indexes), size reduced by 0 bytes (-24 kB including toasts and indexes) in total, approximately 51.85% (19559540 pages) that is 149 GB more were expected to be compacted after this attempt.
WARNING Processing incomplete: 1 tables left.
NOTICE Processing results: size reduced by 0 bytes (-24 kB including toasts and indexes) in total.
NOTICE Retrying to process, attempt: 2 from 10, 1 databases left.
INFO Vacuum initial: 37725024 pages left, duration 414.033 seconds.
NOTICE Statistics: 37725024 pages (80778176 pages including toasts and indexes), approximately 51.85% (19558898 pages) can be compacted reducing the size by 149 GB.

А к ней в это время никто не обращался и т.п.? Что обычные запросы по bloat выдают, и обычный VACUUM VERBOSE?
Я как-то pgcompact не пользовался, но раз он с другими таблицами отработал штатно, должна же быть причина / что-то необычное с этой.

обращений нет.
VACUUM VERBOSE:

INFO:  vacuuming "public.history"
INFO:  index "history_1" now contains 3108546446 row versions in 43036098 pages
DETAIL:  0 index row versions were removed.
20163592 index pages have been deleted, 20163592 are currently reusable.
CPU 234.04s/84.66u sec elapsed 446.86 sec.
INFO:  "history": found 0 removable, 1226491 nonremovable row versions in 7951 out of 37725026 pages
DETAIL:  0 dead row versions cannot be removed yet.
There were 19502 unused item pointers.
Skipped 0 pages due to buffer pins.
0 pages are entirely empty.
CPU 234.14s/85.59u sec elapsed 447.89 sec.

В pg_locks:

-[ RECORD 1 ]------+--------------
locktype           | advisory
database           | 30862
relation           | 
page               | 
tuple              | 
virtualxid         | 
transactionid      | 
classid            | 1259
objid              | 31247
objsubid           | 2
virtualtransaction | 246/0
pid                | 23661
mode               | ExclusiveLock
granted            | t
fastpath           | f

где pid 23661 - процесс pgcompact

INFO:  vacuuming "public.history"
INFO:  index "history_1" now contains 3108546446 row versions in 43036098 pages
DETAIL:  0 index row versions were removed.
20163592 index pages have been deleted, 20163592 are currently reusable.
CPU 234.04s/84.66u sec elapsed 446.86 sec.
INFO:  "history": found 0 removable, 1226491 nonremovable row versions in 7951 out of 37725026 pages
DETAIL:  0 dead row versions cannot be removed yet.
There were 19502 unused item pointers.
Skipped 0 pages due to buffer pins.
0 pages are entirely empty.
CPU 234.14s/85.59u sec elapsed 447.89 sec.

-[ RECORD 1 ]------+--------------
locktype           | advisory
database           | 30862
relation           | 
page               | 
tuple              | 
virtualxid         | 
transactionid      | 
classid            | 1259
objid              | 31247
objsubid           | 2
virtualtransaction | 246/0
pid                | 23661
mode               | ExclusiveLock
granted            | t
fastpath           | f

Странно... а долгих транзакций и т.п. (того, что могло бы задерживать VACUUM) нет, на всякий случай?

моя цель создание базы данных все задач по всем предметам (для начала по математике и физике, затем по всем остальным). Задачи должны разделяться по классам(с 1 класса по 11),на предметы(математика, физика, химия и т.д.), на разделы(в математике это алгебра , геометрия, арифметика и т.д.),на темы, на подтемы, на экзамены (ЕГЭ, ОГЭ, экзамены для поступления в другой ВУЗ), по сложности (например, на 10 уровней сложности), на обычные школьные и олимпиадные задачи, по авторам. Задача может иметь условие, решение, ответ. Кроме того часть задач должны быть во все общем обозрении, а часть по дополнительной подсписке.
Что сможет сделать зарегистрированный пользователь:
1)  Делать выборку по базе данных (по темам, разделам, классам, авторам и т.д.) . То есть как в магазине товаров выбрать задачи и распечатать их в виде pdf
2)  Выбрать задачи случайным образом, задав количество задач,относящихся определенным темам или подтемам и их количество (по аналогии с решу.егэ)
3)  Сохранять выборку задач для разных учеников.

Верно ли составлена схема?