К примеру, на основе "type = LAG(type)" находите границы групп и т.д.

У меня получается такое сделать в несколько итераций.
Вдруг кто-нибудь знает более эффективный способ.

WITH a (id, typ) AS (
 VALUES
   (1, 'a'),
   (2, 'a'),
   (3, 'b'),
   (4, 'b'),
   (5, 'b'),
   (6, 'c'),
   (7, 'c'),
   (8, 'c'),
   (9, 'b'),
   (10, 'b')
)

,b AS (
SELECT
 *,
 CASE WHEN typ != lag(typ) OVER (ORDER BY id) THEN 1 ELSE 0 END grp_flag
FROM
 a
)

,c AS (
SELECT
 *,
 sum(grp_flag) OVER (ORDER BY id) grp
FROM
 b
)

SELECT
 id,
 typ,
 grp,
 min(typ) OVER (PARTITION BY grp) group_typ
FROM
 c;

Добрый день, всем!

Сталкивался ли кто с проблемой функции ts_headline, касающейся ограничения на длинну обрабатываемых слов.  
Имею текст с base64 изображениями в нем.  
При попытке выделения найденного результата "слова" длинной больше 2048 символов просто вырезаются, даже не смотря на то что их не нужно было выделять, это просто прочие слова в тексте.

(на самом деле речь не ос словах, а о закодированном изображении, но если бы это было слово из 3000+ символов - оно бы тоже исчезло из результирующего итога)

основная проблема в том что в моем случае вырезается открывающий тег picture, а закрывающий остается - что ломает мне логику, обработчика.

https://paste.ofcode.org/322qmSP7WZBGXynZ8cKrDcL

Здравствуйте, товарищи по несчастью. Есть вопрос❓есть ли решение для того чтоб реализовать Master Slave, но так чтоб запросы записи и изменения летели на один сервер(Master), а запросы чтения на другой(slave), и всë это было через единую точку подключения и порт?

говорят, что pgpool так умеет, но его ругают

не нашëл где он умеет, то что он как балансировщик нагрузки может выступать это увидел, а вот распределение транзакций R W не нашëл.

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

Здравствуйте. Составляю индекс таблицы. Так как таблица очень большая, создать на ней индекс и проверить как планировщик на него отреагирует весьма долго.

Можно ли как то использовать планировщик с индексом, который я только собираюсь?

Доброе время суток. Виснет pgAdmin и dBeaver когда назначаю столбцу ограничение UNIQUE. Таблица небольшая на 700 строк и 6 столбцов. В чём может быть проблема?

А при создании индекса CONCURRENTLY указываете?

А толку? Полуготовый индекс все равно не будет использоваться.

вот так и работает, чтение с одного, запись в другое.

Нет

В случае с вызовом хранимой процедуры это вообще невозможно реализовать

А попробуйте

Ну и "таблица очень большая" - это достаточно растяжимое понятие. Кто-то и 1 млн записей считает большим числом.

Ну, число не скажу сейчас, но весит 17 гигов

Это тоже мало о чём говорит, т.к. количество столбцов и их тип на это сильно влияют. Но это не важно вообще. Попробуйте создавать индекс с CONCURRENTLY - должно быть сильно быстрее (удалять его тоже надо с CONCURRENTLY). Но вообще проводить эксперименты с созданием индексов на проде я бы не советовал. Надо создать облегчённый дамп (но с таким количеством записей, чтобы планировщик отдавал предпочтение использованию индекса, а не фулскану таблицы).

Так это таблица на деве)

Тогда зачем столько данных в ней?