AS
Это plpgsql, мне нужны эти поля для обработки одинаковых имен.
Хорошо, какая у вас ошибка?
Size: a a a
2021 March 23
IS
Хорошо, какая у вас ошибка?
GroupingError (column \"files.name\" must appear in the GROUP BY clause or be used in an aggregate function\nLINE 1: SELECT name, COUNT(*), array_agg(name ORDER BY name) as ar\n ^\nQUERY: SELECT name, COUNT(*), array_agg(name ORDER BY name) as ar\n FROM files\n WHERE dir_id=file_dir_id AND name ILIKE file_name||'%'\n ORDER BY ar\nCONTEXT: PL/pgSQL function file_update(jsonb) line 24 at SQL statement\n)
KZ
GroupingError (column \"files.name\" must appear in the GROUP BY clause or be used in an aggregate function\nLINE 1: SELECT name, COUNT(*), array_agg(name ORDER BY name) as ar\n ^\nQUERY: SELECT name, COUNT(*), array_agg(name ORDER BY name) as ar\n FROM files\n WHERE dir_id=file_dir_id AND name ILIKE file_name||'%'\n ORDER BY ar\nCONTEXT: PL/pgSQL function file_update(jsonb) line 24 at SQL statement\n)
column \"files.name\" must appear in the GROUP BY clauseAS
GroupingError (column \"files.name\" must appear in the GROUP BY clause or be used in an aggregate function\nLINE 1: SELECT name, COUNT(*), array_agg(name ORDER BY name) as ar\n ^\nQUERY: SELECT name, COUNT(*), array_agg(name ORDER BY name) as ar\n FROM files\n WHERE dir_id=file_dir_id AND name ILIKE file_name||'%'\n ORDER BY ar\nCONTEXT: PL/pgSQL function file_update(jsonb) line 24 at SQL statement\n)
Точно, у вас агрегированный запрос и нету группировки.
Нужно понять, как именно вы хотите сгруиппировать и указать group by.
Возможно вы хотите group by name)
Нужно понять, как именно вы хотите сгруиппировать и указать group by.
Возможно вы хотите group by name)
IS
Точно, у вас агрегированный запрос и нету группировки.
Нужно понять, как именно вы хотите сгруиппировать и указать group by.
Возможно вы хотите group by name)
Нужно понять, как именно вы хотите сгруиппировать и указать group by.
Возможно вы хотите group by name)
невнимательность пошла, думал не GROUP BY, а ORDER BY
AS
невнимательность пошла, думал не GROUP BY, а ORDER BY
Если всё-таки у вас group by name, то в
array_agg(name ORDER BY name) теряется смысл)AL
Приветствую всех!👐
Знающие люди подскажите пожалуйста.
Есть клиент у которого в самом начале рабочего дня,
когда люди начинают использовать сервис (nginx - php-fpm - postgresql - redis(отдельный сервер))
Сервер уходит в 100% CPU, сервис начинает тупить, потом в течении дня нагрузка снижается.
В основном видно что загрузка вызвана процессами PostgreSQL.
Пробовали использовать файловый кэш для приложения, пробовали поднимать лимиты в redis, но нагрузка по CPU не уходит. Пробовали мониторить запросы консольной утилитой, но ничего не увидели, к сожалению DBA у нас нет.
Будем увеличивать количество ядер CPU, но это борьба со следствием,а не причиной.
Встал вопрос мониторинга метрик и вот хочется понять из вашего опыта, что лучше для этих целей использовать, чтобы было можно снять метрики с PostgreSQL и Redis и
понять в чем дело или хотя бы понять направление в котором копать. 🧐
Знающие люди подскажите пожалуйста.
Есть клиент у которого в самом начале рабочего дня,
когда люди начинают использовать сервис (nginx - php-fpm - postgresql - redis(отдельный сервер))
Сервер уходит в 100% CPU, сервис начинает тупить, потом в течении дня нагрузка снижается.
В основном видно что загрузка вызвана процессами PostgreSQL.
Пробовали использовать файловый кэш для приложения, пробовали поднимать лимиты в redis, но нагрузка по CPU не уходит. Пробовали мониторить запросы консольной утилитой, но ничего не увидели, к сожалению DBA у нас нет.
Будем увеличивать количество ядер CPU, но это борьба со следствием,а не причиной.
Встал вопрос мониторинга метрик и вот хочется понять из вашего опыта, что лучше для этих целей использовать, чтобы было можно снять метрики с PostgreSQL и Redis и
понять в чем дело или хотя бы понять направление в котором копать. 🧐
> Сервер уходит в 100% CPU, сервис начинает тупить, потом в течении дня нагрузка снижается.
Нужно выяснить какими запросами вызвана утилизация CPU, смотрите статистику pg_stat_statements. Далее эти запросы уже отдельно анализировать через EXPLAIN - возможно нужны индексы или сам запрос написан неоптимально.
Дополнительно нужно оценить что сервер "аппаратно" соответствует той нагрузке что на него подают - что у сервера достаточно ядер, памяти и производительности дисков.
Также надо посмотреть что не возникают долгие idle транзакции которые также могут приводить к проблемам производительности.
Нужно выяснить какими запросами вызвана утилизация CPU, смотрите статистику pg_stat_statements. Далее эти запросы уже отдельно анализировать через EXPLAIN - возможно нужны индексы или сам запрос написан неоптимально.
Дополнительно нужно оценить что сервер "аппаратно" соответствует той нагрузке что на него подают - что у сервера достаточно ядер, памяти и производительности дисков.
Также надо посмотреть что не возникают долгие idle транзакции которые также могут приводить к проблемам производительности.
FI
Спасибо всем, я понял, что нужно смотреть в сторону информации, которую можно получить из pg_stat_statements. Изучаю доклад https://youtu.be/Hbi2AFhd4nY А что касается самого инструмента, куда это все складывать и отображать, я так понимаю - это вкусовщина
G
Ребят, разбираюсь с транзакциями и уровнями изоляции в PostgeSQL и следующие строки из документации, как по мне, противоречат друг другу.
` Repeatable Read Isolation Level
The Repeatable Read isolation level ... never sees either uncommitted data or changes committed during transaction execution by concurrent transactions
UPDATE, DELETE ... commands behave the same as SELECT in terms of searching for target rows: they will only find target rows that were committed as of the transaction start time. However, such a target row might have already been updated (or deleted or locked) by another concurrent transaction by the time it is found.
`
Вот не понятно, вроде как при этом уровне изоляции внутри транзакции не видны изменения произведенные другими транзакциями, и в тоже время в следующем абзаце написано, что UPDATE, DELETE ... квери могут получить модифицированные данные.
Помогите плз, как это понимать? Спасибо.
` Repeatable Read Isolation Level
The Repeatable Read isolation level ... never sees either uncommitted data or changes committed during transaction execution by concurrent transactions
UPDATE, DELETE ... commands behave the same as SELECT in terms of searching for target rows: they will only find target rows that were committed as of the transaction start time. However, such a target row might have already been updated (or deleted or locked) by another concurrent transaction by the time it is found.
`
Вот не понятно, вроде как при этом уровне изоляции внутри транзакции не видны изменения произведенные другими транзакциями, и в тоже время в следующем абзаце написано, что UPDATE, DELETE ... квери могут получить модифицированные данные.
Помогите плз, как это понимать? Спасибо.
D
RR гарантирует что если ты прочитал какието записи - то при повторном чтении они будут такие же. Если друга транзакция модифицировала какието записи которые ты не трогал (и уже завершилась commit'ом) - и ты их решил прочитать - ты получишь уже обновлённые записи.
D
RR также гарантирует что ты не получишь новые и измененные записи при повторных чтениях - которые были вставлены/изменены после твоего первого чтения. Типа если ты сделал select count с условием - то при повторных select count на эти записи - ты получишь то же самое.
S
такой вопрос. когда делаешь delete from where id 2. строка полностью выпадает. и при добавление через insert into он даст сразу ид 2. т.к он освободился. а как сделать так, чтобы при удаление ид2 заполнялся ид3. ну чтобы они сдвигались.
D
если там sequence то никак
D
потому что - догадайся почему так сделано
S
ну если есть то нельзя, если нет то можно. спс
YS
Ребят, разбираюсь с транзакциями и уровнями изоляции в PostgeSQL и следующие строки из документации, как по мне, противоречат друг другу.
` Repeatable Read Isolation Level
The Repeatable Read isolation level ... never sees either uncommitted data or changes committed during transaction execution by concurrent transactions
UPDATE, DELETE ... commands behave the same as SELECT in terms of searching for target rows: they will only find target rows that were committed as of the transaction start time. However, such a target row might have already been updated (or deleted or locked) by another concurrent transaction by the time it is found.
`
Вот не понятно, вроде как при этом уровне изоляции внутри транзакции не видны изменения произведенные другими транзакциями, и в тоже время в следующем абзаце написано, что UPDATE, DELETE ... квери могут получить модифицированные данные.
Помогите плз, как это понимать? Спасибо.
` Repeatable Read Isolation Level
The Repeatable Read isolation level ... never sees either uncommitted data or changes committed during transaction execution by concurrent transactions
UPDATE, DELETE ... commands behave the same as SELECT in terms of searching for target rows: they will only find target rows that were committed as of the transaction start time. However, such a target row might have already been updated (or deleted or locked) by another concurrent transaction by the time it is found.
`
Вот не понятно, вроде как при этом уровне изоляции внутри транзакции не видны изменения произведенные другими транзакциями, и в тоже время в следующем абзаце написано, что UPDATE, DELETE ... квери могут получить модифицированные данные.
Помогите плз, как это понимать? Спасибо.
> и в тоже время в следующем абзаце написано, что UPDATE, DELETE ... квери могут получить модифицированные данные.
Нет, не написано же.
Написано только то, что при выборке запрос на них "наткнётся". Что будет потом, написано дальше, насколько я помню.
Нет, не написано же.
Написано только то, что при выборке запрос на них "наткнётся". Что будет потом, написано дальше, насколько я помню.
YS
RR гарантирует что если ты прочитал какието записи - то при повторном чтении они будут такие же. Если друга транзакция модифицировала какието записи которые ты не трогал (и уже завершилась commit'ом) - и ты их решил прочитать - ты получишь уже обновлённые записи.
> ты получишь уже обновлённые записи.
Не в PostgreSQL, по крайней мере.
Не в PostgreSQL, по крайней мере.
YS
SexMachina2009
такой вопрос. когда делаешь delete from where id 2. строка полностью выпадает. и при добавление через insert into он даст сразу ид 2. т.к он освободился. а как сделать так, чтобы при удаление ид2 заполнялся ид3. ну чтобы они сдвигались.
Эээ... наоборот же происходит (если речь о sequence). Они ничего "не знают" о данных в таблицах, т.е. при работе с ними в норме и появляются "дыры".
S
ааа ну если есть то можно, если нет то нет. спс
G
Yaroslav Schekin
> и в тоже время в следующем абзаце написано, что UPDATE, DELETE ... квери могут получить модифицированные данные.
Нет, не написано же.
Написано только то, что при выборке запрос на них "наткнётся". Что будет потом, написано дальше, насколько я помню.
Нет, не написано же.
Написано только то, что при выборке запрос на них "наткнётся". Что будет потом, написано дальше, насколько я помню.
я и не говорю что будет в результате работы транзакции, я говорю что транзакция получит модифицированные данные (после селекта выбранные данные окажутся модифицированными). Вот и вопрос, почему так? Ведь написано, что на этом уровне изоляции транзакция не должна видеть изменения произведенные другими транзакиями.