Size: a a a

pgsql – PostgreSQL

2021 June 09

b

batyrmastyr in pgsql – PostgreSQL
Посмотрите как у btrfs сейчас с очисткой старых версий. Во времена ядра 3.16 на дебианах чистка старых версий была лютым геморроем + коряво работала балансировка дерева и он постоянно сваливался в "ой, нет места" (хотя физического места ещё ~20% оставалось). В 4.4 автоматическая балансировка всё ещё не успевала, но проверять как оно на 4.9 или, например, в центоси (в ней, как мне говорили, балансировка ещё в 3.16 работала адекватно) желания уже не было.
источник

LS

Leonid Semeikin in pgsql – PostgreSQL
спасибо! изучу вопрос
источник

PC

Pavel Chernoskutov in pgsql – PostgreSQL
а можно explain обоих запросов
источник

AL

Alexey Lesovsky in pgsql – PostgreSQL
есть такой человек в индустрии Георгий Шуклин (amarao на хабре), он большой фанат btrfs и вообще хорошо шарит во всем что касается эксплуатации систем хранения. Найдите его и проконсультируйтесь, я думаю он вас расскажет массу полезного и интересного по теме btrfs vs. mdadm.

также недавно было интервью от Шишкина (разработчик reiser4), туда в коменты пришли пользователи btrfs и оставили массу полезной инфы о btrfs. Имеет смысл также найти это интервью и почитать как минимум коменты.
источник

LS

Leonid Semeikin in pgsql – PostgreSQL
спасибо =)
источник

LB

Let Eat Bee in pgsql – PostgreSQL
Рабочий @>:

Bitmap Heap Scan on account_users  (cost=16.02..27.95 rows=3 width=91) (actual time=0.055..0.055 rows=0 loops=1)
 Recheck Cond: (account_guids @> '{9dbead55-f2e6-59a8-b4c5-2cf2236bec41}'::uuid[])
 ->  Bitmap Index Scan on account_user_guids_idx  (cost=0.00..16.02 rows=3 width=0) (actual time=0.052..0.052 rows=0 loops=1)
       Index Cond: (account_guids @> '{9dbead55-f2e6-59a8-b4c5-2cf2236bec41}'::uuid[])
Planning Time: 0.187 ms
Execution Time: 0.112 ms

Нерабочий = ANY:


Bitmap Heap Scan on account_users  (cost=8206312.93..8243629.14 rows=3 width=91) (actual time=280.154..280.157 rows=0 loops=1)
 Recheck Cond: (account_guids IS NOT NULL)
 Filter: ('9dbead55-f2e6-59a8-b4c5-2cf2236bec41'::uuid = ANY (account_guids))
 Rows Removed by Filter: 768988
 Heap Blocks: exact=19021
 ->  Bitmap Index Scan on account_user_guids_idx  (cost=0.00..8206312.93 rows=768987 width=0) (actual time=114.046..114.047 rows=769472 loops=1)
Planning Time: 0.281 ms
Execution Time: 280.211 ms
источник

PC

Pavel Chernoskutov in pgsql – PostgreSQL
В правой части конструкции в скобках записывается подзапрос, который должен возвращать ровно один столбец. Вычисленное значение левого выражения сравнивается со значением в каждой строке результата подзапроса с помощью заданного оператора условия, который должен выдавать логическое значение.


https://postgrespro.ru/docs/postgresql/13/functions-subquery
источник

PC

Pavel Chernoskutov in pgsql – PostgreSQL
как мне кажется, вы во втором случае в account_guids и передали всю таблицу, без каких-либо фильтров
источник

PC

Pavel Chernoskutov in pgsql – PostgreSQL
а можно сам запрос?
источник

LB

Let Eat Bee in pgsql – PostgreSQL
explain analyze select * from base.account_users where account_guids @> '{9dbead55-f2e6-59a8-b4c5-2cf2236bec41}';


и

explain analyze select * from base.account_users where '9dbead55-f2e6-59a8-b4c5-2cf2236bec41' = ANY(account_guids);
источник

СГ

Сергей Голод... in pgsql – PostgreSQL
есть ещё вариант с zfs, его не рассматривали?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Да, разница есть. Индексная поддержка (для всех типов индексов, кроме btree — см. значение amsearcharray для каждого access method в исходниках) есть только у первого, насколько я помню (но у GIN точно нет).
источник

LB

Let Eat Bee in pgsql – PostgreSQL
что значит индексная поддержка? @> индексируется корректно же
источник

LB

Let Eat Bee in pgsql – PostgreSQL
Вообще всё началось с того, что JOIN  на результат unnest не использует индекс колонки в unnest. Пришлось делать JOIN LATERAL и WHERE.
источник

PC

Pavel Chernoskutov in pgsql – PostgreSQL
В правой части конструкции в скобках записывается подзапрос, который должен возвращать ровно один столбец.
. Во втором случае, подзапрос и выбирает все записи из базы.
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
А что значит "есть только у первого" в моём ответе, а?

> Есть ли разница между  where arr @> '{value}'  и 'value' = ANY(arr) ?

Мне нужно ещё объяснить, какой из вариантов тут — первый?! ;)

Это значит, что с GIN-index = ANY(arr) поиск по индексу использовать никогда не будет, вот и всё.
источник

LB

Let Eat Bee in pgsql – PostgreSQL
в оригинале не говорится про подзапросы, а про parenthesized expression, which must yield an array value , перевод не точный кмк.
источник

LS

Leonid Semeikin in pgsql – PostgreSQL
рассматривал, btrfs поверхностно выигрывает, не тестировал
источник

PC

Pavel Chernoskutov in pgsql – PostgreSQL
parenthesized expression в данном случае у вас все строки, ибо он никак другим образом их не ограничивает
источник

LB

Let Eat Bee in pgsql – PostgreSQL
нет, постойте. если заставить, то оно "использует" индекс, на как-то по другому: bitmap heap scan проходится по всей таблице. Отсюда и мой вопрос, есть ли семантическа разница в @>`и = ANY` выражениях?
источник