Re: Why does PostgreSQL ftruncate before unlink?
От | Jon Nelson |
---|---|
Тема | Re: Why does PostgreSQL ftruncate before unlink? |
Дата | |
Msg-id | CAKuK5J0ajFMyWSnDGRDdnLSfY7M2vQ2zqRKVHrRscoJe=dEyog@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Why does PostgreSQL ftruncate before unlink? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Why does PostgreSQL ftruncate before unlink?
|
Список | pgsql-general |
On Sun, Feb 23, 2014 at 10:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Jon Nelson <jnelson+pgsql@jamponi.net> writes: >> On Sun, Feb 23, 2014 at 9:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> If memory serves, the inode should get removed during the next checkpoint. > >> I was moments away from commenting to say that I had traced the flow >> of the code to md.c and found the comments there quite illuminating. I >> wonder if there is a different way to solve the underlying issue >> without relying on ftruncate (which seems to be somewhat expensive). > > Hm. The code is designed the way it is on the assumption that ftruncate > doesn't do anything that unlink wouldn't have to do anyway. If it really > is significantly slower on popular filesystems, maybe we need to revisit > that. > Here is an example. % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 99.95 3.207681 4182 767 ftruncate 0.05 0.001579 1 2428 2301 unlink -- Jon
В списке pgsql-general по дате отправления: