Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
От | Greg Stark |
---|---|
Тема | Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) |
Дата | |
Msg-id | 407d949e1001190652i43f4f276x6a485f375647219a@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic
slow createdb)
Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) |
Список | pgsql-performance |
On Mon, Jan 18, 2010 at 4:35 PM, Greg Stark <gsstark@mit.edu> wrote: > Looking at this patch for the commitfest I have a few questions. So I've touched this patch up a bit: 1) moved the posix_fadvise call to a new fd.c function pg_fsync_start(fd,offset,nbytes) which initiates an fsync without waiting on it. Currently it's only implemented with posix_fadvise(DONT_NEED) but I want to look into using sync_file_range in the future -- it looks like this call might be good enough for our checkpoints. 2) advised each 64k chunk as we write it which should avoid poisoning the cache if you do a large create database on an active system. 3) added the promised but afaict missing fsync of the directory -- i think we should actually backpatch this. Barring any objections shall I commit it like this? -- greg -- greg
Вложения
В списке pgsql-performance по дате отправления: