А. Кажется да иначе следующий неймспейс не с нуля стартует

От жеж

X = 7 + n / 2574 Y = 1 + (n % 2574) / 99 Z = 1 + n % 99

Все круто кажется и получилось не так сложно. Без рекурсий и прочего. В итоге если не фильтровать то выдается по строке на неймспейс со следующим id, группы отсортированы по возрастанию, 99 отфильтрованы. Беру только первую строку

Спасибо!

Доброго времени суток. У меня проблема возникла. Кто может советом помочь? В базке выставлено lc_collate=c и ничего с этим поделать не могу. Не получается сделать lower('привет' collate "c.utf-8") что я делаю не так?

У меня вся эта каша в similarity не работает

c.utf-8 это вообще законно?

я у себя такой в pg_collation не вижу

и не понимаю что даже ожидается

c.ut-8 придумали в дебе и вообще неплохая идея

Мотивация была что как-бы почти везде ожидается C но давно и юникод надо

потому c.utf ведедет себя как С а для UTF при сотртировке игнорирует диактрические знаки и акценты

и на экране правильно меряет ширины двухбайтных букв

жаль что пока эта идея не приехала в другие дистрибутивы и софт

именно

а чем ucs_basic не так?

потому c.utf ведедет себя как С а для UTF при сотртировке игнорирует диактрические знаки и акценты

так а че я не так делаю то?

так а че я не так делаю то?

для c.utf нет понятия upper потому что сортировка идет по codepoint, аналогично и в ucs_basic. Upper будет работать только для латиницы

Ну даже если опустить lower и upper то все равно симилярити не работает

я не знаю что такое similarity в конексте посгреса

Все круто кажется и получилось не так сложно. Без рекурсий и прочего. В итоге если не фильтровать то выдается по строке на неймспейс со следующим id, группы отсортированы по возрастанию, 99 отфильтрованы. Беру только первую строку

Я советовал вам немного другое: сделать сиквенс (через CREATE SEQUENCE), наращивать его при генерации нового номера, а сам номер получать вот той арифметикой, основываясь на текущем значении сиквенса.

Добрый день имеется таблица с jsonb. с нее снимается некая статистика для продажников (что именно я не знаю, не дба) хоть и размер таблицы совсем крохотный ~ 2гб запрос идет очень долго, порядка 160 секунд если посмотреть то он упирается в ресурсы cpu (одно из 16-ти ядер при запросе всегда 100% в юзерспейсе) имеем следующие настройки postgres=# show max_parallel_workers_per_gather; max_parallel_workers_per_gather --------------------------------- 8 (1 row) postgres=# show force_parallel_mode; force_parallel_mode --------------------- on (1 row) Вопрос, postgresql распаралеливает seq scan? QUERY PLAN ----------------------------------------------------------------------------------------------------------------- Merge Right Join (cost=2038271.72..1336406075.68 rows=88811045675 width=448) Merge Cond: (boost_invoice.order_id = o.order_id) CTE invoices -> Nested Loop (cost=0.01..851707.13 rows=24221200 width=128) -> Seq Scan on order_atomic_origin orders (cost=0.00..3965.12 rows=242212 width=18) -> Function Scan on jsonb_array_elements invocies (cost=0.01..1.01 rows=100 width=32) CTE orders -> Seq Scan on order_atomic_origin orders_1 (cost=0.00..21525.49 rows=242212 width=356) -> Sort (cost=558840.68..559143.44 rows=121106 width=96) Sort Key: boost_invoice.order_id -> CTE Scan on invoices boost_invoice (cost=0.00..544977.00 rows=121106 width=96) Filter: (market_type = 'boost'::text) -> Materialize (cost=606198.43..3174378.31 rows=146666632 width=384) -> Merge Left Join (cost=606198.43..2807711.73 rows=146666632 width=384) Merge Cond: (o.order_id = cluster_invoice.order_id) -> Sort (cost=47357.75..47963.28 rows=242212 width=320) Sort Key: o.order_id -> CTE Scan on orders o (cost=0.00..4844.24 rows=242212 width=320) -> Materialize (cost=558840.68..559446.21 rows=121106 width=96) -> Sort (cost=558840.68..559143.44 rows=121106 width=96) Sort Key: cluster_invoice.order_id -> CTE Scan on invoices cluster_invoice (cost=0.00..544977.00 rows=121106 width=96) Filter: (market_type = 'cluster'::text)

я не знаю что такое similarity в конексте посгреса

Это функция, которая показывает коэфициент схожести двух слов

Добрый день имеется таблица с jsonb. с нее снимается некая статистика для продажников (что именно я не знаю, не дба) хоть и размер таблицы совсем крохотный ~ 2гб запрос идет очень долго, порядка 160 секунд если посмотреть то он упирается в ресурсы cpu (одно из 16-ти ядер при запросе всегда 100% в юзерспейсе) имеем следующие настройки postgres=# show max_parallel_workers_per_gather; max_parallel_workers_per_gather --------------------------------- 8 (1 row) postgres=# show force_parallel_mode; force_parallel_mode --------------------- on (1 row) Вопрос, postgresql распаралеливает seq scan? QUERY PLAN ----------------------------------------------------------------------------------------------------------------- Merge Right Join (cost=2038271.72..1336406075.68 rows=88811045675 width=448) Merge Cond: (boost_invoice.order_id = o.order_id) CTE invoices -> Nested Loop (cost=0.01..851707.13 rows=24221200 width=128) -> Seq Scan on order_atomic_origin orders (cost=0.00..3965.12 rows=242212 width=18) -> Function Scan on jsonb_array_elements invocies (cost=0.01..1.01 rows=100 width=32) CTE orders -> Seq Scan on order_atomic_origin orders_1 (cost=0.00..21525.49 rows=242212 width=356) -> Sort (cost=558840.68..559143.44 rows=121106 width=96) Sort Key: boost_invoice.order_id -> CTE Scan on invoices boost_invoice (cost=0.00..544977.00 rows=121106 width=96) Filter: (market_type = 'boost'::text) -> Materialize (cost=606198.43..3174378.31 rows=146666632 width=384) -> Merge Left Join (cost=606198.43..2807711.73 rows=146666632 width=384) Merge Cond: (o.order_id = cluster_invoice.order_id) -> Sort (cost=47357.75..47963.28 rows=242212 width=320) Sort Key: o.order_id -> CTE Scan on orders o (cost=0.00..4844.24 rows=242212 width=320) -> Materialize (cost=558840.68..559446.21 rows=121106 width=96) -> Sort (cost=558840.68..559143.44 rows=121106 width=96) Sort Key: cluster_invoice.order_id -> CTE Scan on invoices cluster_invoice (cost=0.00..544977.00 rows=121106 width=96) Filter: (market_type = 'cluster'::text)

Нет.

спасибо

Нет.

Почему нет? Начиная с 9.6

Почему нет? Начиная с 9.6

Я имел в виду "в этом плане (EXPLAIN) —- нет".

А, ок.

косты надо тюнить, чтобы параллельность включилась

косты надо тюнить, чтобы параллельность включилась

Здесь, скорее, что-то мешает (там у автора "force_parallel_mode = on"), хотя кто его знает... надо разбираться в конкретной ситуации.

ну да, на force он тогда ещё снаружи обернёт всё в "и сделать параллельно", если ничего parallel unsafe нет

Почему нет? Начиная с 9.6

стоит PostgreSQL 10.3 on x86_64-pc-linux-gnu

ну да, на force он тогда ещё снаружи обернёт всё в "и сделать параллельно", если ничего parallel unsafe нет

окей, спасибо еще посмотрю.

Ну даже если опустить lower и upper то все равно симилярити не работает

Ну потому и не работает что С, как и другие фунции - триграфы и триграмы работают только в верном collation. Скажем я могу вставить японские иероглифы в us.UTF-8, но эти функции для иероглифов не сработают

Ну потому и не работает что С, как и другие фунции - триграфы и триграмы работают только в верном collation. Скажем я могу вставить японские иероглифы в us.UTF-8, но эти функции для иероглифов не сработают

ну я же пытаюсь преобразовать. или такой вариант не работает?

как вы понимаете я начинающий и очень плохо понимаю что вообще такое LC = C

ну я же пытаюсь преобразовать. или такой вариант не работает?

локаль рассказывает правила, по которым нужно заменять буквы на маленькие или большие

потому что в разных алфавитах одни и те же большие буквы соответствуют разным маленьким

C - это такая локаль, в которой правил нет никаких

потому ничего не происходит

зато быстро ничего не происходит

ну хорошо, это примерно понятно

просто у меня есть БД в которой как раз C этот

и ничего поделать нельзя

а как мне симилярити то использовать

перелить данные в db с корректной collation

"а чего ты ожидала? что вы вдвоём сбежите и будете жить в лесу? он металлический шар, он не может передвигаться, он не хочет жить в лесу, в грязи, в лесу."

перелить данные в db с корректной collation

а преобразовать временно для операции не получиться?

а преобразовать временно для операции не получиться?

TEMP table разве что. Нет других идей

вроде бы всё по инструкции, а рузультата 0

в латинице работает естественно мой similarity

а как он не работает не в латинице?

никак вестимо :-)

а как он не работает не в латинице?

ну есть таблица, в ней столбец, мне необходимо найти более похожие слова, если есть входной кусок

например города всего мира на русском

что такое "никак"?

и входная строка "минс"

оно должно показать что у Минска 95% к примеру совместимость

похожесть вернее

а, ну так он будет регистрозависимым

и резать юникод по половинкам букв

а, ну так он будет регистрозависимым

честно говоря хотелось бы проверить что оно вообще фурычит

есть подозрение что similarity плевать на регистр

начни с полного совпадения

вернее так и есть

начни с полного совпадения

0

минск минск

0

а должно быть 100%

у меня есть БД прод и БД локально

вот на локалке все четко

Доброго времени суток. У меня проблема возникла. Кто может советом помочь? В базке выставлено lc_collate=c и ничего с этим поделать не могу. Не получается сделать lower('привет' collate "c.utf-8") что я делаю не так?

а почему вы пишете lower('привет' collate "c.utf-8") а не lower('ПРИВЕТ' collate "ru_RU.utf-8")?

а почему вы пишете lower('привет' collate "c.utf-8") а не lower('ПРИВЕТ' collate "ru_RU.utf-8")?

щас попробую

и кодировку там не надо указывать

по доке там "ru_RU" по идеи

Попробую повторить свой вопрос утром.

вводные: есть некоторое количество БД размером от 50GB до 1Tb.

хочется делать не менее 4 точек восстановления в день

ну и соотв. хранить промежуточные валы

как корректно расчитать место на диске нужное под это хозяйство, а также что можно использовать чтобы сэкономить дисковое простарнство на бекап сервере?

предполагается использовать barman

а как долго предполагается хранить сделанный бэкап?

а как долго предполагается хранить сделанный бэкап?

хотелось бы хранить месячный, недельный и за последние 7 дней восстановится на любое время. но боюсь слишком много места надо

поэтому хочется формулу по которой можно расчитать приемлимый вариант

А есть на этих выходных постгресовые ивенты в калининграде?

хотелось бы хранить месячный, недельный и за последние 7 дней восстановится на любое время. но боюсь слишком много места надо

а недельные и суточные бэкапы - это по плану должны быть инкрементальные бэкапы?

в общем случае я бы считал так: d - размер базы n - размер изменений файлов данных за сутки m - размер изменений WAL за сутки 4d + 7n + 7m

это не учитывая WAL, необходимый для консистентного восстановления бэкапов недельной давности

и не учитывая компрессию

а компрессия для basebackup разве в barman уж есть?

а недельные и суточные бэкапы - это по плану должны быть инкрементальные бэкапы?

а вот тутх отелось бы совета - как лучше сделать.

и как расчитать размер walов? они ведь генерятся сильно по-разному в зависимости от нагрузки на базу.