YS
Насчет fsync'а у меня уже стоит fsync=off ))
Да, в дополнение к предыдущим советам — если тесты (почему-то) начинаются на "холодных" данных, но Вы уверены, что все они будут нужны — см. https://www.postgresql.org/docs/current/pgprewarm.html
Size: a a a
2020 May 22
MS
Можно даже если ссылаются, но не указано on delete restrict
подскажите тогда куда копать. как именно нужно создать внешний ключ в зависимой таблице чтобы родительская запись в связанной таблице удалялась только тогда, когда на неё никто не ссылается?
YS
подскажите тогда куда копать. как именно нужно создать внешний ключ в зависимой таблице чтобы родительская запись в связанной таблице удалялась только тогда, когда на неё никто не ссылается?
Это по умолчанию так, нет? Или в чём у Вас проблема?
ВЯ
Так и есть
MS
по умолчанию запись в таблице может спокойно существовать, если на неё никто не ссылается в зависимой таблице
MS
есть главная запись в table1. добавляются записи в table2, они все ссылаются на запись в table1 через foreign key. потом удалили все записи из table2 - с этого момента на запись в table1 никто не ссылается, мне нужно автоматически такую запись из table1 удалить. как это можно реализовать?
V
ФК немного не про это. При удалении записи из table2 пытайтесь удалить запись из table1, в случае ошибки ничего не делайте.
MS
а будет ошибка? из-за того, что нарушается целостность (на эту запись есть ссылки)?
V
Да, on delete restrict не даст удалить запись если на нее кто-то ссылается
MS
в общем вроде да, нужно delete restrict повесить, вариант, спасибо
V
Или считайте ссылки на запись руками
MS
Или считайте ссылки на запись руками
окей, вот и ещё тогда вопрос. допустим мы удалим таким образом вообще все строки из table1 - реально удалятся только строки, не задействованные во внешних ключах, а на задействованные мы получим исключение? Или же транзакция просто откатится и нужно по одной записи из table1 просто пытаться проходить и руками удалять и ловить ошибку? Я к тому, что смогу я одной командой delete from table1 удалить нужные строки и не обращать внимания на ошибки внешних ключей (т е чтобы ограничения отработали и такие строки не удалились)?
W
А UNLOGGED таблицы копируются с темплейта? (А вдруг - нет)
YS
в общем вроде да, нужно delete restrict повесить, вариант, спасибо
Хмм... ещё раз, чем Вас поведение по умолчанию не устраивает?
MS
по умолчанию связанная запись не удалится в родительской таблице после того, как на эту запись будут удалены все зависимые строки в другой таблице
s
Yaroslav Schekin
> Фактически это будет как просто сходу всю базу прочитать чтобы она влезла в кэш.
Что в типичном тестировании и так произойдёт, только база "влезет" в shared buffers (что существенно лучше).
> Ну и дополнительно при записи долгого fsync от диска ждать не нужно в принципе.
Тут уже обсуждается fsync=off (ждать ничего не надо, этот аспект tmpfs бесполезен).
Т.е. Вы посчитайте / сравните варианты
1. Отдать под tmpfs столько RAM, чтобы влезла вся база.
2. Просто выкинуть часть той RAM, что была бы использована под tmpfs, и отдать всё, что можно, под shared buffers.
на каком-то конкретном примере — станет понятнее, почему вариант 2 почти наверняка лучше. ;)
Что в типичном тестировании и так произойдёт, только база "влезет" в shared buffers (что существенно лучше).
> Ну и дополнительно при записи долгого fsync от диска ждать не нужно в принципе.
Тут уже обсуждается fsync=off (ждать ничего не надо, этот аспект tmpfs бесполезен).
Т.е. Вы посчитайте / сравните варианты
1. Отдать под tmpfs столько RAM, чтобы влезла вся база.
2. Просто выкинуть часть той RAM, что была бы использована под tmpfs, и отдать всё, что можно, под shared buffers.
на каком-то конкретном примере — станет понятнее, почему вариант 2 почти наверняка лучше. ;)
Да тут вопрос в том, что если много писать, то быстрее сразу в оперативку записать нежели на диск (что несомненно окажется и в shared_buffers заодно). Минус долгая запись на медленный диск, хоть скорее всего с tmpfs будет немного медленнее выгребать данные нежели из shared_buffers.
fsync=off или fsync=on в контексте tmpfs безразлично - у нее нет backing device. Оно мгновенно отвечает "Готово". Ну syscall не делаем разве что лишний каждый раз.
Так что тут зависит от соотношения времени на заполнение тестовыми данными и на прогон тестов. Если тесты прям сильно дольше делаются - правда ваша. Если сравнимо по времени или дольше заполняется - tmpfs выиграет практически гарантированно.
fsync=off или fsync=on в контексте tmpfs безразлично - у нее нет backing device. Оно мгновенно отвечает "Готово". Ну syscall не делаем разве что лишний каждый раз.
Так что тут зависит от соотношения времени на заполнение тестовыми данными и на прогон тестов. Если тесты прям сильно дольше делаются - правда ваша. Если сравнимо по времени или дольше заполняется - tmpfs выиграет практически гарантированно.
s
окей, вот и ещё тогда вопрос. допустим мы удалим таким образом вообще все строки из table1 - реально удалятся только строки, не задействованные во внешних ключах, а на задействованные мы получим исключение? Или же транзакция просто откатится и нужно по одной записи из table1 просто пытаться проходить и руками удалять и ловить ошибку? Я к тому, что смогу я одной командой delete from table1 удалить нужные строки и не обращать внимания на ошибки внешних ключей (т е чтобы ограничения отработали и такие строки не удалились)?
Откатится
YS
по умолчанию связанная запись не удалится в родительской таблице после того, как на эту запись будут удалены все зависимые строки в другой таблице
И с RESTRICT будет ровно то же самое. Ещё раз, зачем он Вам нужен?
s
Транзакция это либо всё, либо ничего. Не вдаваясь в нюансы.
KK
не могу найти пример преобразования результата вложенных запросов в xml