а где он должен быть то?

в неймспейсе наверное

ок, посмотрю)

В системе в качестве ключей хранятся uuidы вместо привычного цифрового id. Но все колонки в которых они лежат имеют тип не UUID а просто текст. Имеет ли смысл переделывать? Постгрес будет как то иначе их обрабатывать? Поменял тип и явного прироста в скорости не увидел

В системе в качестве ключей хранятся uuidы вместо привычного цифрового id. Но все колонки в которых они лежат имеют тип не UUID а просто текст. Имеет ли смысл переделывать? Постгрес будет как то иначе их обрабатывать? Поменял тип и явного прироста в скорости не увидел

В принципе, они компактнее, да. А как Вы меняли, и какого прироста / в каких запросах ожидали (Вы измеряли, или это так, "по ощущениям")?

В системе в качестве ключей хранятся uuidы вместо привычного цифрового id. Но все колонки в которых они лежат имеют тип не UUID а просто текст. Имеет ли смысл переделывать? Постгрес будет как то иначе их обрабатывать? Поменял тип и явного прироста в скорости не увидел

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

В принципе, они компактнее, да. А как Вы меняли, и какого прироста / в каких запросах ожидали (Вы измеряли, или это так, "по ощущениям")?

Точно не измерял чисто на глаз. Если запрос выполялся 800ms то стал 760 допустим, те разницы почти никакой нет это может что угодно так ускорить мб просто потому что индексы свежие стали

а еще: 2) индексы будут компактнее 3) данные не будут выноситься в toast

Точно не измерял чисто на глаз. Если запрос выполялся 800ms то стал 760 допустим, те разницы почти никакой нет это может что угодно так ускорить мб просто потому что индексы свежие стали

> Точно не измерял чисто на глаз. Тогда это всё без толку... Вы же знаете, небось. :) Но существенного увеличения производительности я бы и не ожидал, в большинстве случаев.

Точно не измерял чисто на глаз. Если запрос выполялся 800ms то стал 760 допустим, те разницы почти никакой нет это может что угодно так ускорить мб просто потому что индексы свежие стали

запрос на 800ms скорее всего тормозит не из-за типов данных

Хранить uuid просто соответствующим типом / как 16 байт - это хороший тон, но не обязательный.

Точно не измерял чисто на глаз. Если запрос выполялся 800ms то стал 760 допустим, те разницы почти никакой нет это может что угодно так ускорить мб просто потому что индексы свежие стали

Но я бы всё же хранил UUID как UUID, а не text. Просто чтобы лишнее место не тратить.

всем привет! какой оператор более эффективный IN или ANY, а может еще какая альтернатива?

нагуглить не получилось

посмотри в план

ну может есть какое устоявшееся мнение?

ну может есть какое устоявшееся мнение?

план запроса ответит тебе на твой вопрос

всем привет! какой оператор более эффективный IN или ANY, а может еще какая альтернатива?

понятие более эффективного оператора тут не уместно. они не во всех случаях равнозначны логически, а там где равнозначны нужно смотреть планы запроса

понятие более эффективного оператора тут не уместно. они не во всех случаях равнозначны логически, а там где равнозначны нужно смотреть планы запроса

спасибо!)

всем привет! какой оператор более эффективный IN или ANY, а может еще какая альтернатива?

Всё равно

всем привет! какой оператор более эффективный IN или ANY, а может еще какая альтернатива?

А альтернатива чему? Откуда у Вас то, что в IN/ANY, из подзапроса? Или список значений?

А альтернатива чему? Откуда у Вас то, что в IN/ANY, из подзапроса? Или список значений?

список значений. Но вроде уже сказали, что зависит от запроса и прямых указаниый на превосходство одного над другим нет

список значений. Но вроде уже сказали, что зависит от запроса и прямых указаниый на превосходство одного над другим нет

Ну, не только. Запросы у Вас параметризованные, я надеюсь? Если да, лучше использовать "= ANY ($array)".

Ах, да — API должно поддерживать передачу параметров-массивов (не все умеют).

да, параметризованные

Ну, не только. Запросы у Вас параметризованные, я надеюсь? Если да, лучше использовать "= ANY ($array)".

спасибо!

Если gin висит, то лучше @@ использовать, чтобы индекс юзался

Точнее, @>, <@

да, параметризованные

Всё равно, проверьте. Кажется, на psycopg2 ругались, что с виду всё хорошо, а на самом деле используется string substitution (если не путаю). :(

Кстати, в Pgfe всё по-честному - запросы параметризованные, причём с именованными параметрами. Ну и полноценная поддержка N-мерных массивов Постгреса с отображением в любой N-мерный STL-контейнер. Используйте Pgfe. ?

Ребята, можете помочь со сборкой pglogical? Внутренние ресурсы закончились... Необходимо собрать pglogical под Windows Server R2 Standart 64-bit для PostgreSQL 9.5.12. Что было сделано.... Изучена инструкция - https://blog.2ndquadrant.com/compiling-postgresql-extensions-visual-studio-windows/ Установлена Visual Studio 2017 под винду. Создан проект. Загружен код из репозитория https://github.com/2ndQuadrant/pglogical При попытке сборки первая ошибка что нет пути к файлу postgres.h Гугл говорит, что файл postgres.h можно найти в исходниках постгреса. Скачаны исходники постгреса версии 9.5.12, в свойствах проекта прописаны пути к ним. Результат отрицательный - куча ошибок на отсутствие необходимых файлов. Основные вопросы: 1. Как указать компилятору, под какую версию постгреса должен быть собран pglogical? 2. Какие пути и где должны быть прописаны? 3. Что я делаю не так?

Собирал

Павел, спасибо за готовую сборку, но может отсталась какая-нибудь виртуалка с настроенным окружением или инструкция по сборке? Нужно собрать под определённую версию - PostgreSQL 9.5.12 Не такое это простое дело, как оказалось.

а из докер файла не пробовали подергать команды?

там послдовательность воспроизводимая как собрать

а из докер файла не пробовали подергать команды?

Неа

попробуйте)

Пытались использовать готовую сборку под 9.6, но из-за несовместимости новой и старой версий ничего не заработало.

Павел, спасибо за готовую сборку, но может отсталась какая-нибудь виртуалка с настроенным окружением или инструкция по сборке? Нужно собрать под определённую версию - PostgreSQL 9.5.12 Не такое это простое дело, как оказалось.

Напомните завтра, плз. Либо соберу, либо напишу как. Не помню живо ли окружение

Ок. Благодарю)))

Пока не за что )))

Я всё равно ничего не понял. Результат попытки выполнения конкурентных UPDATE (даже без SELECT), зависит от уровня изоляции, разве нет?

Вот тоже интересно :) select for update лочит запись, так что другие for update будут ждать. Но вот дока говорит, что если у этих других транзакция уровня выше RR, то их транзакция все равно отменится.. зачем ждать им тогда непонятно, на случай если транзакция с локом отменится что-ли?

Вот тоже интересно :) select for update лочит запись, так что другие for update будут ждать. Но вот дока говорит, что если у этих других транзакция уровня выше RR, то их транзакция все равно отменится.. зачем ждать им тогда непонятно, на случай если транзакция с локом отменится что-ли?

Да, на этот случай. Можно использовать NOWAIT, если это не нужно.

Да и вообще, если все равно ждать, то зачем отменять >=RR? Ведь после ожидания будут новые данные, как будто транзакция началась после их коммита

Да и вообще, если все равно ждать, то зачем отменять >=RR? Ведь после ожидания будут новые данные, как будто транзакция началась после их коммита

На SERIALIZABLE это дало бы "рваный" snapshot, т.е. аномалии. Тут понятно. На RR логика, видимо, в том, что это Non-repeatable read.

На SERIALIZABLE это дало бы "рваный" snapshot, т.е. аномалии. Тут понятно. На RR логика, видимо, в том, что это Non-repeatable read.

Что такое рваный снапшот? Вот начинается вторая транзакция, она seralized, первой же запрос в ней select for update. Она ждёт пока закомитится предыдущая транзакция и вылетает с конфликтом. Чем этот вылет "лучше" , чем просто продолжить? Ведь данные будут такие же, будто ждущая транзакция началась после предыдущей

я не следил за вашей дискуссией, но вполне возможно что write skew

Что такое рваный снапшот? Вот начинается вторая транзакция, она seralized, первой же запрос в ней select for update. Она ждёт пока закомитится предыдущая транзакция и вылетает с конфликтом. Чем этот вылет "лучше" , чем просто продолжить? Ведь данные будут такие же, будто ждущая транзакция началась после предыдущей

Во-первых, это крайний случай (вообще редко когда на SERIALIZABLE делают SELECT FOR UPDATE, мне кажется). Во-вторых, это бы сработало, только если а) в первом запросе б) все выбираемые FOR UPDATE rows в) были бы ранее locked одной и той же транзакцией... и уже не слишком ли это (а может быть, есть и другие обязательные условия, дальше не думал)?

@serboox будет жить. Поприветствуем!

Что такое рваный снапшот? Вот начинается вторая транзакция, она seralized, первой же запрос в ней select for update. Она ждёт пока закомитится предыдущая транзакция и вылетает с конфликтом. Чем этот вылет "лучше" , чем просто продолжить? Ведь данные будут такие же, будто ждущая транзакция началась после предыдущей

Я думаю, что тут такой нобор случаев 1. Первая транзакция взяла for update, стартанула вторая транзакция и тоже хочет for update, после первая откатывается, тогда вторая может продолжить работу, ведь данные не изменены и соответствуют на момент старта второй. 2. Первая взяла for update, потом вторая, потом первая сделал а комит без изменения данных. Скорей всего вторая может просто продолжить работу 3. Первая взяла for update, потом вторая, первая сделал а комит, второй придётся кидать ошибку, так как данные изменены другой транзакцией и не соответствуют на момент старта второй. Эти случаи вроде как для => RR. Для RC скорей всего ошибка не кидается, она как раз может продолжить работу после блокировки. Я не проверял, позже проверю. Вообще я думал, что никаких блокировок >= RR не бывает, сразу ошибка кидается.

Я думаю, что тут такой нобор случаев 1. Первая транзакция взяла for update, стартанула вторая транзакция и тоже хочет for update, после первая откатывается, тогда вторая может продолжить работу, ведь данные не изменены и соответствуют на момент старта второй. 2. Первая взяла for update, потом вторая, потом первая сделал а комит без изменения данных. Скорей всего вторая может просто продолжить работу 3. Первая взяла for update, потом вторая, первая сделал а комит, второй придётся кидать ошибку, так как данные изменены другой транзакцией и не соответствуют на момент старта второй. Эти случаи вроде как для => RR. Для RC скорей всего ошибка не кидается, она как раз может продолжить работу после блокировки. Я не проверял, позже проверю. Вообще я думал, что никаких блокировок >= RR не бывает, сразу ошибка кидается.

Проверил, так и работает. И при >= RR действительно блокируется. Вообщем-то неудивительно, что именно так это работает, если вы знаете, от каких аномалий спасает каждый уровень изоляции (в данном случение RR).

Добрый день! Накатал тест/статью PostgreSQL https://habr.com/post/422461/ Приглашаю заценить)

неплохо

про нахождение подстроки и регулярки только скучновато

Добрый день! Накатал тест/статью PostgreSQL https://habr.com/post/422461/ Приглашаю заценить)

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

Скажи это JS программистам, там иногда невероятную наркоманию спрашивают, потому что язык много чего позволяет), но естественно, в здравом уме, никто делать так не будет как в примерах)

Понял Я закладывал обучающий характер, проблема - ответ Нежели реальный тест на собеседовании

а уж sum от ::TEXT - это смешно, конечно, но как нормального человека это может даже интересовать?

не, инетересовать может, но это же не использовать. а если приходится, то из-за идиота до тебя, который сделал числовое поле строкой и тебе надо там конвертировать.

короче, идея подачи этих мест, как вопросов на собеседовании, ИМХО, не очень хорошая

короче, идея подачи этих мест, как вопросов на собеседовании, ИМХО, не очень хорошая

Блин, в моей голове звучало по другому) что все задачи на join и тд

Блин, в моей голове звучало по другому) что все задачи на join и тд

тут, наверное, все-таки проблема в том, что я искал людей не по их знаниям, а по тому, смогут ли они найти решение. а уж знаю они в данный момент coalesce или нет - не важно.

Тут очевидно речь про parent_id is Null SELECT * FROM any_table WHERE parent_id = parent_id; SELECT * FROM any_table WHERE parent_id IS NOT DISTINCT FROM parent_id наши CodeFirst ждуны обычно не знают что в SQL Null <> Null ))

Тут очевидно речь про parent_id is Null SELECT * FROM any_table WHERE parent_id = parent_id; SELECT * FROM any_table WHERE parent_id IS NOT DISTINCT FROM parent_id наши CodeFirst ждуны обычно не знают что в SQL Null <> Null ))

> наши CodeFirst ждуны обычно не знают что в SQL Null <> Null А это тоже неверно, кстати. ;) "Null <> Null" -> NULL

Добрый день! Накатал тест/статью PostgreSQL https://habr.com/post/422461/ Приглашаю заценить)

(Пролистал) Вот зачем нужны вопросы типа 13, мне интересно? Нет бы спросить, как правильно работать с транзакциями... Но нет, обязательно надо делать умный вид, расспрашивая про конкретные особенности поведения READ COMMITTED в PostgreSQL. :(

(Пролистал) Вот зачем нужны вопросы типа 13, мне интересно? Нет бы спросить, как правильно работать с транзакциями... Но нет, обязательно надо делать умный вид, расспрашивая про конкретные особенности поведения READ COMMITTED в PostgreSQL. :(

Наверное не стоило скрывать ответы

Наверное не стоило скрывать ответы

А причём тут это? Не стоит задавать такие вопросы, IMHO.

А причём тут это? Не стоит задавать такие вопросы, IMHO.

Это мало кто знает А объяснить можно что-то на конкретном примере

Это мало кто знает А объяснить можно что-то на конкретном примере

Так давайте, например, лесорубов при трудоустройстве спрашивать: "Как правильно отпилить себе левую руку? А если правую в это время отпиливает кто-то другой?" Это же мало кто знает, правильно? ;)

А причём тут это? Не стоит задавать такие вопросы, IMHO.

Тут же вспомнилось. - Вы хотите все время задавать вопросы или хотите слышать мои ответы? (с) Путин

Так давайте, например, лесорубов при трудоустройстве спрашивать: "Как правильно отпилить себе левую руку? А если правую в это время отпиливает кто-то другой?" Это же мало кто знает, правильно? ;)

Если есть цепная пила, то руку можно отпиливать ногами. Правильно?

Если есть цепная пила, то руку можно отпиливать ногами. Правильно?

Да пусть отпиливают, как им нравится — я бы предпочёл, эээ... тихо удалиться с собеседования, где мне задают такие вопросы. ;)

Добрый день! Накатал тест/статью PostgreSQL https://habr.com/post/422461/ Приглашаю заценить)

Лично я считаю, что на собеседовании можно задавать любые вопросы. Но, если бы на вашем собеседовании были только эти вопросы, то я бы его не прошёл, ведь я не знаю ответа почти на каждый. В 13-ом не понимаю сценарий, когда user_1 ввёл команду на увеличение на 5. В тот момент, когда пользователь User_2 вводит свою команду, команда от User_1 завершилась или она в процессе?

Убрал эту фразу, вызывает проблемы при чтении по диагонали

Кроме собеседования никто ничего не увидел Добавил лишь для привлечения внимания, а зря

Кроме собеседования никто ничего не увидел Добавил лишь для привлечения внимания, а зря

Допустим, но я всё равно не понимаю, как вот это может быть "тонкостью" или "типичным рабочим моментом" (и зачем вообще это знать ;) ): > Как вычислить количество ЗАГЛАВНЫХ (английских) букв в строке с помощью SQL? > Как посчитать сумму чисел (не цифр) в строке с помощью SQL То же самое касается вопроса номер 13. Мало того, что он сформулирован нечётко (может быть несколько исходов, включая неожиданные), но и, опять-таки, зачем это знать?

@BRenat будет жить. Поприветствуем!

Всем привет. У меня тут вопрос по джоинам таблиц

если джоины идут друг за другом то джоин происходит по результатам предыдущего джоина? ` LEFT JOIN "zones" ON "zones"."organization_id" = "user_organizations"."organization_id" LEFT JOIN "groups" ON "groups"."organization_id" = "zones"."organization_id" ` Вот группы приджонятся относительно выбранных зон или относительно всей таблицы зон?