Почему не используется GIN индекс в Postgresql с установкой веса?

просто для себя

https://github.com/postgres/postgres/blob/REL_11_S...

For backwards-compatibility reasons, we allow an expression that's just a function call to be written without parens.

То есть для gin(func(column)) намеренно сделано исключение чтобы не ломать более старый код. Если бы это была новая фича - то тоже требовали бы явные скобки.

Почему не используется GIN индекс в Postgresql с установкой веса?

Нужны ещё скобки. gin((func1 || func2))

Почему не используется GIN индекс в Postgresql с установкой веса?

то есть для условия (func1 || func2) operator operand в общем случае возможно использовать только index((func1 || func2))
то есть выражение в индексе должно совпадать с тем выражением, по которому ведём поиск.

Что означает индекс в выводе var_dump для объекта?

значит var_dump даёт ту строку, на которую я сослался.

Pg_basebackup, зависит ли скорость копирования от типа данных преобладающих в БД и можно ли как-то увеличить скорость копирования средствами postgres?

Saboteur, давайте зайдём с другой стороны: а с чего вы вообще взяли, что автор вопроса использует сжатие?

В первом случае убедитесь, что -z включено и попробуйте -Z 9

Это ничего не изменит. Команда репликационного протокола BASE_BACKUP отправляет только несжатые данные. Поэтому с любым -Z по репликации пройдёт один и тот же объём данных.

Во втором случае попробуйте наоборот -Z 1, чтобы уменьшить нагрузку на CPU

А если упираетесь в один поток CPU - то выключите сжатие. Отсутствие сжатия совершенно очевидно будет быстрее любого уровня сжатия с точки зрения утилизации CPU. Его необходимо включать намеренно. Это не дефолтное поведение.

Как сочетать type и depth в команде find?

То что я процитировал их написанного в man. Обрабатывать сначала содержимое директории, потом её саму. Например, при удалении.

Как сделать так, чтобы INSERT выполнился по результату SELECT атомарно?

ну и напоследок, вот так что получится?
t1: start transaction
t2: start transaction
t1: select
t2: select
t1: insert
t1: commit
t2: insert
t2: commit

Как сделать так, чтобы INSERT выполнился по результату SELECT атомарно?

Могло быть хуже. На serializable всегда надо быть готовым повторить транзакцию заново.

возможно ситуацию улучшит если сделать select ... for update. Но я не знаю как в точности serializable работает в mysql. Известно что как блокировочник, а вот где и какие локи при этом берёт - не знаю.

Как сделать так, чтобы INSERT выполнился по результату SELECT атомарно?

ага. А если исполнять команды по очереди в двух консолях:
t1: start transaction
t2: start transaction
t1: select
t2: select
t1: insert
t2: insert
где транзакция2 ждать начнёт?

Как сделать так, чтобы INSERT выполнился по результату SELECT атомарно?

Транзакции выполняются полностью последовательно на этом уровне

Утверждение не верно.
На этом уровне результат транзакции должен быть такой же, как при последовательном выполнении этих же транзакций. Это не то же самое, что исполняются последовательно.

Однако не уверен, что реализация serializable в mysql/innodb корректна для этого случая. Напишите как проверите, интересно (но не настолько чтобы ставить mysql).

create table foo (i int);
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
start transaction;
select * from foo where i != 5;
insert into foo values (5);
-- до коммита сделайте со второй консоли такие же запросы начиная с set transaction, затем коммит в обеих
-- при корректной реализации второй коммит разрешён не должен быть.
commit;

Pg_basebackup, зависит ли скорость копирования от типа данных преобладающих в БД и можно ли как-то увеличить скорость копирования средствами postgres?

1. на диск пишется тогда уже сжатый, да.
2. потому что -Z задаёт уровень компрессии для -z. Который, как я уже писал, делает только сам pg_basebackup. Если его снимать по сети - то это не изменит объём пересылаемых данных.

Pg_basebackup, зависит ли скорость копирования от типа данных преобладающих в БД и можно ли как-то увеличить скорость копирования средствами postgres?

могу вам ответственно сказать как контрибьютор: любой -Z никак не повлияет на сеть и не уменьшит нагрузку на CPU.
-z в pg_basebackup есть только для format tar, при том сжимает данные только непосредственно сам pg_basebackup.
Поэтому включать сжатие имеет смысл только если вы хотите сэкономить место на диске. Ни по сети ни по CPU ничего выиграть не получится.
https://github.com/postgres/postgres/blob/REL_11_S...

RAID10: Как ремапить софтварный RAID10, если "вылетел" один из дисков? Как расчитать скорость ремапа RAID10?

1) mdadm /dev/md? -f /dev/sd? ; заменяете диск ; mdadm /dev/md? -a /dev/sd?
операция штатная, если не ошибиться в именах устройств,то дальшележащая файловая система не узнает, что что-то вообще происходило.
2) фактора два:
- надо записать объём данных равный размеру этого тома. То есть 10тб / среднюю скорость последовательной записи
- чтобы было что записать, это что-то сперва надо прочитать. Если у вас layout дефолтный near2 - то 10тб / скорость чтения одного парного диска. То есть зависит от нагрузки на оставшийся парный диск, ведь информацию надо сперва прочитать. Для offset и far - блоки будут размазаны по всем дискам и соответственно больше дисков будет использоваться для чтения. Кроме совсем загруженных случаев упрётся в скорость записи на новый диск.
3) linux raid10 нельзя рассматривать как зеркало поверх страйпа или страйп поверх зеркала. Это один массив (а для разных layout и пишется по-разному). Ядро отлично понимает, что если выпал один диск - только блоки которые должны быть на нём и надо восстанавливать при ребилде.

RAID6 vs RAID10+LVM почему 10тка себя неадекватно ведет после нагрузки на диски больше 50%(LA по iowait лимитирует к 100% )?

Ничего касательно "быстрее" у вас на графике не вижу.

Не сталкивался. Просто прокомментировал что для linux raid 10 по дефолту картина неравномерной утилизации пар дисков характерна, исправляется сборкой offset2

RAID6 vs RAID10+LVM почему 10тка себя неадекватно ведет после нагрузки на диски больше 50%(LA по iowait лимитирует к 100% )?

При чем первый stripe из RAID10 нагружен при пиковых нагрузках на 10-15% больше за второй

Это нормально для дефолтного распределения. Соберите его с --layout=o2, будет куда более ровно по всем дискам.

Postgresql: пустой ответ на запрос при наличии записей: сбой или есть причина?

Просто отключите кеширование данных запросов

если бы postgresql понял, что кэш устарел, он запросил бы их заново из таблицы

Мне очень интересно, где вы в postgresql нашли кэш запросов.
Нет его, никогда не было и не будет. В mysql - единственной мне известной СУБД где когда-то был кэш запросов - его уже тоже нет.

Ну а если вы про внешний кэш говорите - то откуда бы базе узнать, что тот протух?

покажите select vesion();

Какую версию php лучше поставить 7.0, 7.2 или 7.3?

Sanes, вы о чём? mbstring как был так и остался: https://github.com/php/php-src/tree/PHP-7.3/ext/mb...
И в 7.4 он тоже будет там же где и раньше: https://github.com/php/php-src/tree/PHP-7.4/ext/mb...

Как выбрать несколько значений из базы данных?

Ну так mysql_fetch_row совершенно очевидно возвращает одну строку из результата. Потому что так и должна работать.

Код рабочий только когда имя не содержит пробелов. Имя находится в бд MySQL в чем проблема?

все таки проблема в javascript коде

вот именно к этому я и веду. Это хоть и не непосредственная причина, но отличная точка где всё-таки можно остановиться и задать вопрос уже очень сильно меньше в размере.
Но зачем вы оставили весь код связанный с БД? var_dump($_POST) в результате ajax запроса - или ещё лучше репорт из средств разработчика браузера, что данные так и были отправлены. То есть обработчик этого ajax запроса можно из рассмотрения выбросить целиком. Какой в нём смысл, если данные ему уже отправляют повреждёнными?
Раз проблема судя по всему на клиентской стороне - выбросьте из вопроса и формирование html тоже. Замените на статический html. В ajax запросе всё ещё только одно слово? Значит ни субд ни php никакого отношения к проблеме не имеют.
И вот уже рассматриваем не 3 листинга, а один js плюс одну строку html.

Отгадка.
И ошибка не касается языков программирования. JS тоже тут ни при чём. Вообще. Серьёзно. Ошибка просто в HTML
<input name=user required>
Чему равен name? "user required"? Нет? Почему? Отличается ли этот пример от вашего HTML?
<div class=doom data-plusw=my name>
Нет. Всё тот же самый парсер HTML, который по историческим причинам вынужден пытаться прожевать практически что угодно и не возмущаться при этом. Есть некий атрибут name без значения, а для атрибута data-plusw значением является только my.
<div class="doom" data-plusw="my name">
А так есть атрибут data-plusw со значением my name
Потому пробел и играет решающую роль: он изменяет разметку документа. И потому же это критичная ошибка безопасности, XSS называется.

'<div class="doom" data-plusw="' . htmlspecialchars($author['user']) . '">'

Код рабочий только когда имя не содержит пробелов. Имя находится в бд MySQL в чем проблема?

Продолжайте упрощать. Всё ещё слишком много лишнего.
Что у вас в $_POST пришло? Что отправил браузер?

spoiler

div class=doom row или div class="doom row" - в чём разница? Что будет атрибут HTML, а что его значением?