Re: 9.4 regression
От | Jon Nelson |
---|---|
Тема | Re: 9.4 regression |
Дата | |
Msg-id | CAKuK5J0s9ZikBxUTdLW4zF=yXYrBzk0WwiM=-fX_xJ3Hes5jrg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: 9.4 regression (Hannu Krosing <hannu@2ndQuadrant.com>) |
Ответы |
Re: 9.4 regression
Re: 9.4 regression Re: 9.4 regression |
Список | pgsql-hackers |
On Thu, Aug 8, 2013 at 2:50 PM, Hannu Krosing <hannu@2ndquadrant.com> wrote: > On 08/08/2013 05:28 PM, Jon Nelson wrote: ... > Just an idea - can you check if using a fillfactor different form 100 > changes anything > > pgbench -s 20 -p 54320 -d pgb -F 90 -i > > >> pgbench -j 80 -c 80 -T 120 -p 54320 pgb >> pg_ctl -D tt -w stop > > That is, does extending tables and indexes to add updated tuples play > any role here I gave it a go - it didn't make any difference at all. At this point I'm convinced that the issue is a pathological case in ext4. The performance impact disappears as soon as the unwritten extent(s) are written to with real data. Thus, even though allocating files with posix_fallocate is - frequently - orders of magnitude quicker than doing it with write(2), the subsequent re-write can be more expensive. At least, that's what I'm gathering from the various threads. Why this issue didn't crop up in earlier testing and why I can't seem to make test_fallocate do it (even when I modify test_fallocate to write to the newly-allocated file in a mostly-random fashion) has me baffled. Should this feature be reconsidered? -- Jon
В списке pgsql-hackers по дате отправления: