Pull to refresh

Comments 16

Вы молодцы. Спасибо, за ваш вклад.
Очень хотелось бы почитать про новые возможности полнотекстового поиска.
Вот здесь можно посмотреть http://www.sai.msu.su/~megera/postgres/talks/pgopen-2016-rum.pdf и ранняя версия доклада http://www.sai.msu.su/~megera/postgres/talks/pgcon-2016-fts.pdf
Про CoreServer ничего говорить не стану — все на высоте.
А вот новая pgAdmin 4, которую разрабы делали 10.000 часов и применили JQuery, выглядит очень стремно — лучше бы не пытались. Даже иконки не поменяли — перетянули с 3 версии.
Поддержу по поводу pgAdmin 4. Я надеялся, что третью версию просто перепишут на какой-нибудь современный кроссплатформенный gui (qt5 или gtk3 например). Третья версия, как по мне — почти идеал, вот только проблемы на mac и на hidpi. Но то, что там сотворили в четвертой — просто ужасно. Пробовал последнюю предрелизную бету (или как там она называлась) — баги лезли буквально с первой секунды работы. Знаю, что сейчас вышла релизная, еще не пробовал ее, но то количество багов, по-моему, просто нереально было исправить за такой короткий срок. Да и сама идея делать клиентские приложения для PC на технологиях web'а меня удручает.
Тем не менее, тенденция именно такова. Это проще и дешевле…
Ужасное поделие…
Грузится минут 5, инструмент по управлению сессиями урезали (он их просто отображает без возможности прибить). Как может быть админский инструмент без этого?
Будет ли краткий синтаксис добавления новых элементов в JSONB на замену jsonb_set? Оператором #- можно удобно произвести удаление элемента на любой вложенности документа, хотелось бы такой же краткости с || (или новым #+).
Многие этого давно хотят! Так что будет.

Круто, спасибо!


Расскажите, пожалуйста, чуть подробнее (по русски и может чуть более простым языком) о:


Вычисление выражений в SELECT после ORDER и LIMIT, если это возможно
Вот простой пример.
SELECT random() r, pg_sleep(1) FROM generate_series(1,10) ORDER BY r LIMIT 1;

В 9.5 и ниже pg_sleep() будет вычислены до того, как будет выполнен ORDER BY и LIMIT. Поэтому запрос длится чуть больше 10 секунд.
В 9.6 pg_sleep() будет выполнен после ORDER BY и LIMIT, поэтому запрос будет длиться чуть больше одной секунды.

Напишите ещё, пожалуйста, о планах выпуска вашего дистрибутива, Postgres Pro 9.6 и поддержки 9.6 в ваших расширениях (меня очень сильно pg_pathman привлекает, сейчас обновляемся с 9.4 на 9.5 именно из-за него, хотели бы и сразу на 9.6 прыгнуть).

По поводу выполнения функций после ORDER and LIMIT: а что если в отсекаемой части вычислений будет ошибка? Деление на ноль, например. Верно ли понимаю, что раньше оно бы не дало вернуть результаты, а в 9.6 не помешает и результаты появятся?

Попробовал на 9.5 сейчас сделать деление на ноль, которое выскакивало бы только после LIMIT-а, но видимо запрос был слишком простым и вычисления не проводились.
Вот пример с делением.
CREATE OR REPLACE FUNCTION slow_div(bigint, bigint) RETURNS bigint AS
$$
  BEGIN
    RETURN $1 / $2;
  END;
$$ LANGUAGE plpgsql COST 1000;
SELECT slow_div(1, 10 - g) FROM generate_series(1,10) g ORDER BY g LIMIT 1;

Для того, чтобы постгрес отложил вычисление функции, нужно ей cost по-больше задать.
На 9.5 этот запрос у меня возвращает ошибку «division by zero», в 9.6 успешно возвращает одну строку.
Ребят вы молодцы, статья просто супер. Работал ранее на MongoDB, перешел на Postgres и не жалею ни капли.
Спасибо за ваш труд.
Спасибо Вам большое за Ваш вклад! Новые фичи просто огонь, особенно для полнотекстового поиска.
Sign up to leave a comment.