Re: PostgreSQL on RAM Disk / tmpfs
От | Thomas F. O'Connell |
---|---|
Тема | Re: PostgreSQL on RAM Disk / tmpfs |
Дата | |
Msg-id | A02581DF-D835-456B-8E40-6276A3568525@sitening.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL on RAM Disk / tmpfs ("Merlin Moncure" <mmoncure@gmail.com>) |
Ответы |
Re: PostgreSQL on RAM Disk / tmpfs
|
Список | pgsql-general |
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 cluster same-table statements together in a transaction in an effort to reduce disk activity make any difference? 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? -- Thomas F. O'Connell Sitening, LLC http://www.sitening.com/ 3004B Poston Avenue Nashville, TN 37203-1314 615-469-5150 x802 615-469-5151 (fax)
В списке pgsql-general по дате отправления: