9.1 --> 9.4

добрый день, недавно на новом месте и недавно на postgres
но вот что увидел: используется старая версия 9.1.14
подскажите плиз как можно обновится на 9.4? :
1.надо постепенно с версии на верисю (9.1 --> 9.2 --> 9.3 --> 9.4) или 9.1 --> 9.4
2.будут ли изменения в текущих функциях, данных, и т.п. что может сказаться на работе приложения которое использует хранение на постгресе

Legushka,

1. нет, можно сразу
2. могут быть небольшие изменения, а может вообще не быть. Зависит от того, что у вас используется.

Сделайте dump 9.1 & restore 9.4, чтобы посмотреть на ошибки и предупреждения.

Legushka
используется старая версия 9.1.14

Почему Вы считаете это старой версией?
Как Вы обосновываете необходимость перехода?

/\/\/\/\/\/\
Legushka используется старая версия 9.1.14 Почему Вы считаете это старой версией? Как Вы обосновываете необходимость перехода?

по мне -- LATERAL слишком вкусная шняжка, чтобы её избегать.

очень здорово упрощает многие трюки в части их написания руками, практически -- целая горничная, евпочя

[quot /\/\/\/\/\/\]

Legushka
Как Вы обосновываете необходимость перехода?

есть текстовые поля в которых хранятся json данные, и сейчас значения эти просто достаются по ИД из БД во внешнее приложение и там уже обрабатываются

есть желание для ускорения получить работу с json средствами постгреса+создание индексов по json
тогда еще можно создать умный поиск

это уже оправдывает переход

Legushka,

На сколько процентов и за счет чего произойдет ускорение?
Мне это действительно интересно. А так же методика подсчета.

Имеется ли в наличие достаточное количество программистов БД, чтобы провести ускорение в разумные сроки (не через 2 года).

/\/\/\/\/\/\
На сколько процентов и за счет чего произойдет ускорение? Мне это действительно интересно. А так же методика подсчета.

Мы сейчас экспериментируем с новым поиском по фильтрам (тегам) на сайте. Отлично работает, можно отказаться от join к справочникам.

Возможно, если объединить теги с нормализованными формами ("fts":...) из tsvector, поиск вообще начнет работать по единственной таблице и одному индексу. Индекс очень компактный, а селективность превосходная. На старой нормализованной структуре это работало раза в два дольше.

explain (analyze,buffers)
select articlecode,tagjb -->'fts'
from cache.salepricearticlescache 
where tagjb @> '{"fts": ["белый", "красный", "ручка"], "tags": [{"tid": 21, "id": [10, 12]},{"tid": 5, "id": [1]}]}' and Level =1

Bitmap Heap Scan on salepricearticlescache  (cost=412.26..605.19 rows=50 width=273) (actual time=4.514..5.250 rows=39 loops=1)
  Recheck Cond: ((tagjb @> '{"fts": ["белый", "красный", "ручка"], "tags": [{"id": [10, 12], "tid": 21}, {"id": [1], "tid": 5}]}'::jsonb) AND (level = 1))
  Heap Blocks: exact=39
  Buffers: shared hit=185
  ->  Bitmap Index Scan on i_cache_salepricearticlescache_jsonb_opt  (cost=0.00..412.25 rows=50 width=0) (actual time=4.449..4.449 rows=39 loops=1)
        Index Cond: (tagjb @> '{"fts": ["белый", "красный", "ручка"], "tags": [{"id": [10, 12], "tid": 21}, {"id": [1], "tid": 5}]}'::jsonb)
        Buffers: shared hit=131
Planning time: 1.905 ms
Execution time: 5.299 ms