GS
pg_probackup release 2.4.9:
https://github.com/postgrespro/pg_probackup/releases/tag/2.4.9
https://github.com/postgrespro/pg_probackup/releases/tag/2.4.9
Size: a a a
2021 January 27
R
Добрый день. В таблице teams есть два поля (leader_id и curator_id) которые ссылаются на таблицу users. Как можно получить это одном запросом? То есть одного пользователя могу left join, А что делать со вторым?
am
Добрый день. В таблице teams есть два поля (leader_id и curator_id) которые ссылаются на таблицу users. Как можно получить это одном запросом? То есть одного пользователя могу left join, А что делать со вторым?
У джоинов могут быть aliases.
LEFT JOIN users curators ON curators.id = teams.curator_id и тд.R
У джоинов могут быть aliases.
LEFT JOIN users curators ON curators.id = teams.curator_id и тд.Спасибо, кажется понял
@
КОМРАДЫ а куда 4г пропал?
4
тут я - код мерджил :/
KZ
@skynet
Оракл дичь. Был крут пока пг был в зародыше.
Ясно😂😂😂😂😂
VY
Yaroslav Schekin
(Побуду адвокатом дьявола) Ну а если меня всё это не убеждает? ;)
Т.е. у массивов-то есть нумерация, а вот у result sets нет порядка. Где в документации PostgreSQL явно указано, что результат Set-Returning Function от массива должен как-то относиться к порядку его элементов? Опять-таки, где указано, что порядок rows, возвращаемых SRF, не может быть изменён до применения к ним ORDINALITY?
Т.е. у массивов-то есть нумерация, а вот у result sets нет порядка. Где в документации PostgreSQL явно указано, что результат Set-Returning Function от массива должен как-то относиться к порядку его элементов? Опять-таки, где указано, что порядок rows, возвращаемых SRF, не может быть изменён до применения к ним ORDINALITY?
YS
Хмм... и вот, к вопросу о том, насколько хорошо мы понимаем английский:
I think 7.2.1.4 is clear enough:
А вообще — документацию улучшили, приятно. :)
I think 7.2.1.4 is clear enough:
If the WITH ORDINALITY clause is specified, an additional column ofИм-то виднее, мне кажется.
type bigint will be added to the function result columns. This column
numbers the rows of the function result set, starting from 1.
А вообще — документацию улучшили, приятно. :)
VY
Была же история про какую-то компанию, которая переходила с mysql на postgres потом обратно потому что разочаровались. Убер вроде, можно погуглить, они подробный обзор писали, что их не устроило. Потом люди им отвечали в статьях, что они не правильно его настраивали и вот всё такое.
их основная (и справедливая) претензия к Postgres-у — Write Amplification, когда изменение одной колонки приводит к массовому изменению всех индексов и бывает больно по IO.
в 12, 13 и 14 версиях над индексами круто поработали и подобные эффекты сведены к минимуму.
в 12, 13 и 14 версиях над индексами круто поработали и подобные эффекты сведены к минимуму.
M
Это я завтра ещё хочу спросить про остальные табличные функции. Не только же unnest есть. Для многих других функций тоже порядок в доке прописывать?
M
Yaroslav Schekin
Хмм... и вот, к вопросу о том, насколько хорошо мы понимаем английский:
I think 7.2.1.4 is clear enough:
А вообще — документацию улучшили, приятно. :)
I think 7.2.1.4 is clear enough:
If the WITH ORDINALITY clause is specified, an additional column ofИм-то виднее, мне кажется.
type bigint will be added to the function result columns. This column
numbers the rows of the function result set, starting from 1.
А вообще — документацию улучшили, приятно. :)
Я так понимаю, что имеется в виду, что функция может вернуть упорядоченный набор. То есть свойство порядка - это фича функции, потому он и не увидел тут проблем, мне кажется
am
их основная (и справедливая) претензия к Postgres-у — Write Amplification, когда изменение одной колонки приводит к массовому изменению всех индексов и бывает больно по IO.
в 12, 13 и 14 версиях над индексами круто поработали и подобные эффекты сведены к минимуму.
в 12, 13 и 14 версиях над индексами круто поработали и подобные эффекты сведены к минимуму.
Хех. Я тут как раз обновился с 11 до 13 и столкнулся с тем, что запись стала сильно тормозить. Разбираюсь по-тихоньку.
VY
Я так понимаю, что имеется в виду, что функция может вернуть упорядоченный набор. То есть свойство порядка - это фича функции, потому он и не увидел тут проблем, мне кажется
я бы даже сказал, что для ORDINALITY всё равно, они просто нумеруют записи так, как их возвращает ф-ция. и именно поэтому в части
7.2.1.4 он сказал, что всё прозрачно.VY
Хех. Я тут как раз обновился с 11 до 13 и столкнулся с тем, что запись стала сильно тормозить. Разбираюсь по-тихоньку.
я бы рекомендовал перестроить индексы ( ради интереса зафиксируйте их размер до и после ).
благо есть удобный
благо есть удобный
REINDEX TABLE CONCURRENTLY !M
я бы даже сказал, что для ORDINALITY всё равно, они просто нумеруют записи так, как их возвращает ф-ция. и именно поэтому в части
7.2.1.4 он сказал, что всё прозрачно.Наверно. Но есть ещё как минимум одна функция, в доку по которой тоже стоит добавить упоминание про порядок - jsonb_to_recordset
M
Наверно. Но есть ещё как минимум одна функция, в доку по которой тоже стоит добавить упоминание про порядок - jsonb_to_recordset
Если нет, то у меня возникнет вопрос "почему" )
am
я бы рекомендовал перестроить индексы ( ради интереса зафиксируйте их размер до и после ).
благо есть удобный
благо есть удобный
REINDEX TABLE CONCURRENTLY !Да, как раз на очереди идей
REINDEX по большой таблице, где проблема, кажется, была изолирована.KZ
Если нет, то у меня возникнет вопрос "почему" )
Формально может быть предложена оптимизация для больших jsonb с параллельным выполнением функции)))
M
Формально может быть предложена оптимизация для больших jsonb с параллельным выполнением функции)))
Да может, но хочется, конечно, чтобы семантика массивов и в json-е сохранилась. А кстати, для обычных массивов тоже такой аргумент мог бы быть?