| From: | "Thomas F(dot) O'Connell" <tfo(at)sitening(dot)com> | 
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> | 
| Cc: | PgSQL-General <pgsql-general(at)postgresql(dot)org> | 
| Subject: | Re: PostgreSQL on RAM Disk / tmpfs | 
| Date: | 2006-08-08 21:51:09 | 
| Message-ID: | A02581DF-D835-456B-8E40-6276A3568525@sitening.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
On Aug 8, 2006, at 1:10 PM, Merlin Moncure wrote:
> On 8/8/06, Thomas F. O'Connell <tfo(at)sitening(dot)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)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Erik Jones | 2006-08-08 22:39:43 | Re: Why is default value not working on insert? | 
| Previous Message | Jasbinder Bali | 2006-08-08 21:45:59 | Re: DB connectivity from a client machine |