Search Postgresql Archives

Re: PostgreSQL on RAM Disk / tmpfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/8/06, Thomas F. O'Connell <tfo@xxxxxxxxxxxx> wrote:

On Aug 8, 2006, at 1:10 PM, Merlin Moncure wrote:

> On 8/8/06, Thomas F. O'Connell <tfo@xxxxxxxxxxxx> 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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux