Re: PostgreSQL on RAM Disk / tmpfs
От | Merlin Moncure |
---|---|
Тема | Re: PostgreSQL on RAM Disk / tmpfs |
Дата | |
Msg-id | b42b73150608081654s4112f202q353686b412f950b7@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL on RAM Disk / tmpfs ("Thomas F. O'Connell" <tfo@sitening.com>) |
Список | pgsql-general |
On 8/8/06, Thomas F. O'Connell <tfo@sitening.com> wrote: > > On Aug 8, 2006, at 1:10 PM, Merlin Moncure wrote: > > > On 8/8/06, Thomas F. O'Connell <tfo@sitening.com> wrote: > >> On Aug 3, 2006, at 1:26 PM, Merlin Moncure wrote: > >> > if have super high write volumes, consider writing your insert > >> call in > >> > C. prepare your statement, and use the parameterized > >> > version....ExecPrepared(...). > >> > >> Can you point to a good example of this anywhere in the docs? I don't > >> see ExecPrepared anywhere in the core documentation. > > > > well, it's actually PQexecPrepared() > > http://www.postgresql.org/docs/8.1/interactive/libpq-exec.html > > > > do some tests and you should see a nice improvement over PQexec(). > > Thanks! > > I remain curious, though: in the event that a RAM-disk-based > architecture remains in place, do all traditional disk-based > considerations go out the window? For instance, does trying to if you are not syncing, the computer essentially is a giant ram disk. the operating system just pages ram to disk here and there to free up more ram for temporary demands. while kernel buffers are slower than local process memory, they are still awfully fast compared to disk drives. operating systems thes days are pretty good about deciding what should and should not stay in ram, better than most people believe. it's *usually* a rookie sysadmin move to force things into memory this way. another common sysadmin misadventure is to turn off the o/s swap file. > cluster same-table statements together in a transaction in an effort > to reduce disk activity make any difference? there is still a small savings due to optimizng transaction cleanup although you have to handle failures which can be a downside. > And is the overall strategy of attempting to keep distance between > checkpoints somewhat high (especially since the need for > checkpointing overall is reduced) still a good basis? depends. with fsync=off, usually the only time you are worried about checkpoints is during bullk load, and i think in these cases you will want to increase wal segments and leave the bgwriter alone. merlin
В списке pgsql-general по дате отправления: