@pgsql
Stanislav02.02.2018
10:44:44
10:44:44
Mykyta02.02.2018
10:45:10
10:45:10
Google
Stas02.02.2018
10:48:45
10:48:45
Ну дык одно из этих полей не уникальное
https://www.postgresql.org/docs/10/static/indexes-unique.html
The index covers the columns that make up the primary key or unique constraint (a multicolumn index, if appropriate)
Evgeniy02.02.2018
10:49:39
10:49:39
я загрузил базу по новой
Раньше этот же запрос работал нормально
мб analyze поможет если раньше все работало и ты ничего не потерял при восстановлении
Леонид02.02.2018
10:50:02
10:50:02
мб analyze поможет если раньше все работало и ты ничего не потерял при восстановлении
сейчас пытаюсь понять что не таки что может быть не так
когда убираешь один left join
и все работает
Evgeniy02.02.2018
10:50:55
10:50:55
джоин коллапс лимит?
Леонид02.02.2018
10:50:57
10:50:57
потом его добавляешь и все зависает
Леонид02.02.2018
10:51:13
10:51:13
потом убираешь другой left join а этот добавляешь и тоже работает
Ilia02.02.2018
10:51:42
10:51:42
Это нормально
GoogleEvgeniy02.02.2018
10:51:53
10:51:53
таблиц в запросе больше восьми?
Evgeniy02.02.2018
10:52:36
10:52:36
значит смотри на настройку выше
Ilia02.02.2018
10:52:38
10:52:38
Они статистику соберут...
Ilia02.02.2018
10:53:20
10:53:20
Это он говорит, что есть, это не значит, что есть...
Ilia02.02.2018
10:53:48
10:53:48
Это значит что он уверен что есть.
Леонид02.02.2018
10:53:53
10:53:53
там даже около 10-11 таблиц
Ilia02.02.2018
10:54:01
10:54:01
Ну ладно
Yaroslav02.02.2018
10:54:30
10:54:30
Леонид02.02.2018
10:55:45
10:55:45
той у которой 100кк
Yaroslav02.02.2018
10:56:05
10:56:05
там даже около 10-11 таблиц
Пробовали поднять from_collapse_limit / join_collapse_limit до 11-12 (по _моему_ опыту время планирования при этом всё ещё приемлемое в большинстве случаев)?GoogleStanislav02.02.2018
10:56:50
10:56:50
Всем привет! Парни, начал вчера изучать psql по работе, и все бы хорошо, но возник небольшой вопрос. Допустим есть таблица:
id, project_id, task_id
Так вот, я хочу при инсерте быть увереным (делать проверку) что в подмножестве с одинаковым project_id все task_id должны быть уникальными.
Подскажите в какую сторону копать?
повторюсь на всякий случай. Набор данных примерно такой:
1 2
1 3
1 4
2 2
2 3
2 4Yaroslav02.02.2018
10:57:57
10:57:57
нет пока
Значит, если autovacuum/analyze ещё не добрался до остальных таблиц, планы строятся фактически наудачу.
Т.е. смотреть что-то особого толка нет.Леонид02.02.2018
10:58:47
10:58:47
Пробовали поднять from_collapse_limit / join_collapse_limit до 11-12 (по _моему_ опыту время планирования при этом всё ещё приемлемое в большинстве случаев)?
попробовать поставить в настройках
from_collapse_limit 11
join_collapse_limit 11и перезапустить сервер?
мб поможет
Yaroslav02.02.2018
10:59:19
10:59:19
повторюсь на всякий случай. Набор данных примерно такой:
1 2
1 3
1 4
2 2
2 3
2 4
Так чем Вам unique index не подошёл?Леонид02.02.2018
10:59:32
10:59:32
потом попробую сделать autovacuum/analyze всей базы
Evgeniy02.02.2018
10:59:38
10:59:38
попробовать поставить в настройках
from_collapse_limit 11
join_collapse_limit 11
да, даже ребутать не надоEvgeniy02.02.2018
10:59:41
10:59:41
сессионные
Stanislav02.02.2018
10:59:48
10:59:48
Так чем Вам unique index не подошёл?
если я повешу на оба поля unique то они оба должны содержать уникальные значения, но в моем случае это не такIlia02.02.2018
10:59:57
10:59:57
Значит, если autovacuum/analyze ещё не добрался до остальных таблиц, планы строятся фактически наудачу.
Т.е. смотреть что-то особого толка нет.
Он же все индексы создал...
При этом разве статистика не собирается?Evgeniy02.02.2018
11:00:09
11:00:09
Darafei02.02.2018
11:00:11
11:00:11
Yaroslav02.02.2018
11:00:19
11:00:19
если я повешу на оба поля unique то они оба должны содержать уникальные значения, но в моем случае это не так
Вам же составной индекс советовали... чем он не подошёл?Evgeniy02.02.2018
11:00:35
11:00:35
если я повешу на оба поля unique то они оба должны содержать уникальные значения, но в моем случае это не так
господи, не два отдельных индекса а один на два роляStanislav02.02.2018
11:00:54
11:00:54
GoogleStanislav02.02.2018
11:01:19
11:01:19
спасибо, сейчас попробую
KitsuЛеонид02.02.2018
11:07:49
11:07:49
поставил 11
from и join
спасиб
Evgeniy02.02.2018
11:10:03
11:10:03
гуд
Yaroslav02.02.2018
11:10:51
11:10:51
спасиб
Вы лучше всегда делайте VACUUM ANALYZE после восстановления SQL-дампа (созданного pg_dump).
(vacuumdb или просто "VACUUM ANALYZE;")
А иначе у Вас будут получаться случайные планы. ;)Леонид02.02.2018
11:12:20
11:12:20
на ту таблицу с домами
там 100 млн и каждый день приходит несколько млн апдейтов
правильно ли так?
Yaroslav02.02.2018
11:13:32
11:13:32
Ну это же совсем другое. Это Вы параметры autovacuum/autoanalyze настраиваете.
А сразу после восставновления дампа у Вас есть только базовая статистика, т.е. планировщик начинает просто гадать при построении планов.
Леонид02.02.2018
11:15:04
11:15:04
там не совсем из дампа востанавливал
просто создал новую бд
и запустил импорт данных по новой
Yaroslav02.02.2018
11:16:58
11:16:58
GoogleYaroslav02.02.2018
11:17:57
11:17:57
Ilia02.02.2018
11:21:50
11:21:50
КЛАДР
Yaroslav02.02.2018
11:21:50
11:21:50
для базы в 100гб
Да, возможно это будет долго... но альтернатив-то особо и нет.
Т.е. выбирайте: хреновые планы или vacuumdb.
Кстати, есть ещё vacuumdb —analyze-in-stagesЛеонид02.02.2018
11:22:16
11:22:16
Да, возможно это будет долго... но альтернатив-то особо и нет.
Т.е. выбирайте: хреновые планы или vacuumdb.
Кстати, есть ещё vacuumdb —analyze-in-stages
запустил VACUUM ANALYZE; из навикатанадеюсь норм будет
Yaroslav02.02.2018
11:23:52
11:23:52
Леонид02.02.2018
11:24:03
11:24:03
тоже важно тут?
Yaroslav02.02.2018
11:24:55
11:24:55
тоже важно тут?
https://www.postgresql.org/docs/10/static/runtime-config-query.html#GUC-DEFAULT-STATISTICS-TARGETЛеонид02.02.2018
11:28:08
11:28:08
спастб
Andrew02.02.2018
13:09:00
13:09:00
господа
подскажите пожалуйста а pgconf-2018 будет ли потом видео лекций? платно или бесплатно?
Pavel02.02.2018
13:11:42
13:11:42
Открыть в Telegram