Size: a a a

pgsql – PostgreSQL

2020 May 25

YS

Yaroslav Schekin in pgsql – PostgreSQL
Сергей Голод
теперь постгреспро выпустили версию, которая с одной стороны решила тот случай но привела к другому вопросу о правильности работы ванильного постгреса. Должен ли постгрес при пересоздании индекса использовать именно пересозданный, а не тот индекс, который более быстрый.
Хмм... в смысле (я не понял вопроса, если честно)?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Сергей Голод
что именно внесли в исходный код - мне неизвестно (исходники патчей публично недоступны)
Т.е. они не дали вообще никаких пояснений?
источник

GS

Grigory Smolkin in pgsql – PostgreSQL
Сергей Голод
что именно внесли в исходный код - мне неизвестно (исходники патчей публично недоступны)
src пакеты же есть у 1с сборки
источник

СГ

Сергей Голод... in pgsql – PostgreSQL
Grigory Smolkin
src пакеты же есть у 1с сборки
есть пачти к 1С от 1С, есть патчи от постгреспро. Первые достпны, вторые нет. Сейчас поясню ситуацию
источник

GS

Grigory Smolkin in pgsql – PostgreSQL
Почему нет, если src пакеты есть
источник

GS

Grigory Smolkin in pgsql – PostgreSQL
Для постгреспро сборки
источник

СГ

Сергей Голод... in pgsql – PostgreSQL
Grigory Smolkin
Почему нет, если src пакеты есть
источник

СГ

Сергей Голод... in pgsql – PostgreSQL
study=# \d+ _inforg4491
                                             Table "public._inforg4491"
    Column     |            Type             | Collation | Nullable | Default | Storage
----------------+-----------------------------+-----------+----------+---------+--------
_period        | timestamp without time zone |           | not null |         | plain  
_recordertref  | bytea                       |           | not null |         | plain  
_recorderrref  | bytea                       |           | not null |         | plain  
_lineno        | numeric(9,0)                |           | not null |         | main  
_active        | boolean                     |           | not null |         | plain  
_fld4492rref   | bytea                       |           | not null |         | plain  
_fld10536rref  | bytea                       |           | not null |         | plain  
_fld4493rref   | bytea                       |           | not null |         | plain  
_fld4494       | numeric(15,5)               |           | not null |         | main  
_fld5774_type  | bytea                       |           | not null |         | plain  
_fld5774_rtref | bytea                       |           | not null |         | plain  
_fld5774_rrref | bytea                       |           | not null |         | plain  
Indexes:
   "_inforg4491_bydims" UNIQUE, btree (_fld4492rref, _fld10536rref, _fld4493rref, _period, _recordertref, _recorderrref, _lineno, _active)
   "_inforg4491_bydims4496" UNIQUE, btree (_fld4493rref, _period, _recordertref, _recorderrref, _lineno, _active)
   "_inforg4491_byperiod" UNIQUE, btree (_period, _recordertref, _recorderrref, _lineno)
Access method: heap
источник

СГ

Сергей Голод... in pgsql – PostgreSQL
вот таблица. Есть три индекса, _byperiod, _bydims, _bydims4496
источник

GS

Grigory Smolkin in pgsql – PostgreSQL
источник

GS

Grigory Smolkin in pgsql – PostgreSQL
Действительно, недоступно
источник

СГ

Сергей Голод... in pgsql – PostgreSQL
при выполнении запроса - строится правильный план, в который включаются индексы _bydims и _bydims449. Но как только я удаляю индекс _byperiod и заново его создаю (полностью идентичный) - то при построении плана начинает использовать именно этот индекс, который я создал последним. хотя в таблице по прежнему присутствуют два индекса, которые до пересоздания byperiod корректно использовались.

вопрос - правильное ли такое поведение ванильного постгреса?
источник

СГ

Сергей Голод... in pgsql – PostgreSQL
дамп таблицы и текст запроса могу выложить
источник

СГ

Сергей Голод... in pgsql – PostgreSQL
Grigory Smolkin
Действительно, недоступно
)))
источник

СГ

Сергей Голод... in pgsql – PostgreSQL
выполнение vacuum, vacuum full, vacuum full analyze ситуацию не меняет. Всё равно используется _byperiod. Чтобы начали использоваться _bydims/_bydims4496 нужно пересоздать теперь их
источник

СГ

Сергей Голод... in pgsql – PostgreSQL
источник

СГ

Сергей Голод... in pgsql – PostgreSQL
стоит ли открывать тикет или это ожидаемое поведение? (последний создаваемый индекс является приоритетным)
источник

VY

Victor Yegorov in pgsql – PostgreSQL
Сергей Голод
стоит ли открывать тикет или это ожидаемое поведение? (последний создаваемый индекс является приоритетным)
посмотрите как меняется размер индекса после пересоздания, это может влиять на выбор. я сомневаюсь, что там есть логика “последний созданный в приоритете”.
я бы смотрел как меняются планы и косты в планах до и после пересоздания индекса
источник

СГ

Сергей Голод... in pgsql – PostgreSQL
Victor Yegorov
посмотрите как меняется размер индекса после пересоздания, это может влиять на выбор. я сомневаюсь, что там есть логика “последний созданный в приоритете”.
я бы смотрел как меняются планы и косты в планах до и после пересоздания индекса
состояние индексов при первичном создании таблицы из дампа:

schemaname |  tablename  |       indexname        |   num_rows   | table_size | index_size | unique |
------------+-------------+------------------------+--------------+------------+------------+--------+
public     | _inforg4491 | _inforg4491_bydims     | 4.868718e+06 | 845 MB     | 654 MB     | Y      |
public     | _inforg4491 | _inforg4491_bydims4496 | 4.868718e+06 | 845 MB     | 443 MB     | Y      |
public     | _inforg4491 | _inforg4491_byperiod   | 4.868718e+06 | 845 MB     | 315 MB     | Y      |
(3 rows)

после пересоздания индекса:

schemaname |  tablename  |       indexname        |   num_rows   | table_size | index_size | unique |
------------+-------------+------------------------+--------------+------------+------------+--------+
public     | _inforg4491 | _inforg4491_bydims     | 4.868718e+06 | 845 MB     | 654 MB     | Y      |
public     | _inforg4491 | _inforg4491_bydims4496 | 4.868718e+06 | 845 MB     | 443 MB     | Y      |
public     | _inforg4491 | _inforg4491_byperiod   | 4.868718e+06 | 845 MB     | 315 MB     | Y      |
(3 rows)
источник

СГ

Сергей Голод... in pgsql – PostgreSQL
размеры полностью идентичны
источник