с одним то всё просто

получается да, по умолчанию тоже самое. суть совета в другом - чтобы пробовать удалять записи из родительской таблицы и обрабатывать исключения ограничения целостности, вот до этого я не додумался

> что если много писать, то быстрее сразу в оперативку записать нежели на диск

Да. Но с unlogged tables + "fsync=off" + "increase max_wal_size and checkpoint_timeout" (всё из приведённой ранее ссылки) у PostgreSQL никакой необходимости спешить с этим нет.

Т.е. сразу после загрузки данных можно начинать тестировать.

> Ну syscall не делаем разве что лишний каждый раз.

Хотя бы... ;) Но, так или иначе, в этой ситуации — это не преимущество tmpfs.

> Если сравнимо по времени или дольше заполняется - tmpfs выиграет практически гарантированно.

Хмм... не понимаю, почему, можете пояснить?
И я же писал про распределение RAM, в первую очередь.
Конечно, если (допустим) тестовых данных 8 Гб, а всего (доступной / ненужной) памяти 128 Гб — тут можно и инициализировать кластер гигабайт на 16 на tmpfs, и сделать shared_buffers = 16 Гб — но обычно так не бывает (что памяти "слишком много"), IMHO. ;)

Хм, а удалять с where not exists (blah blah) не будет ли существенно дешевле такой транзакции с откатом?
Кстати говоря, если во второй таблице записей много, то нужно к foreign key ещё соответствующий индекс создать, он сам по умолчанию не создаётся.

это да, читал про это, учтём

Почему в одно поле FK я могу вставить значение через INSERT, а в другой таблице, тоже поле FK не могу, ругается (ERROR:  column "id_pacient" of relation "diagnosis" does not exist

там ещё сложность в том, что есть каскадное удаление, в общем сделаю попытку удаления родительской связанной записи после зависимой в триггере)

Возможно что с индексом это будет быстрее... Тестировать надо

похоже, что поля такого нет, чудес не бывает, посмотри перечень столбцов в diagnosis

Каскадное будет удалять все записи table2 которые ссылаются на table1 при удалении из table1. Вам это точно требуется?

каскадное будет удалять все записи из table2, но и все записи из table1, на которые больше никто не ссылается из table2 после каскадного удаления. Да, именно такая логика, такое потребовалось)

"Выиграет" имеется в виду за счёт того, что запишет данные существенно быстрее, а выбирать для тестов будет не сильно медленнее даже если shared_buffers не делать таким, чтобы всё влезло. Оверхед больше, но память всё равно чертовски быстрая.

Это всё, конечно, и правда, так будет только в случае, если постгрес таки начнет писать на диск. Если выкрутить его на максимально отложенную запись настолько, что тесты пройдут быстрее -  да, так tmpfs тоже быстрее не будет.

@viking_unet Эмм.. Что?

Так вот, казалось бы, да... Но какой-то минимум записи всё равно будет (по крайней мере, в FS — современная OS/FS тоже не кинется всё это писать, пока у неё есть избыток памяти, и ничто (fsync) её не заставляет ;) ),  по мере relation extensions и т.п.
В общем, если RAM "слишком много" — это лучше измерить, чем рассуждать, Ваша правда. :)

да не заморачивайтесь.. есть абстрактный объект, который живёт, пока живёт группа физических объектов, как только все физические объекты удаляются, то и абстрактный объект должен исчезнуть

Триггер Вам поможет.

я на него рассчитываю, они редко подводят)

а существует ли способ загнать значения всех полей в xml, не перечисляя каждое?

Пытаюсь вот эту команду выполнить

> pg_dump database > outfile

bash: outfile: Permission denied

Подумал, что проблема с пользователем, попылатся сделать

> du

Но выводит не таблицу, а просто список файлов. Не подскажете, в чём может быть проблема? Пытаюсь в своём пет проекте разобраться

Хотя ладно, внезапно получилось