-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/14/07 10:09, Phoenix Kiula wrote:
> On 14/08/07, Gregory Stark <stark@enterprisedb.com> wrote:
>> "Phoenix Kiula" <phoenix.kiula@gmail.com> writes:
[snip]
>>>
>>> QUESTION1:
>>> Is this it? Or am I missing something in terms of execution? We use
>>> Perl on our site but may be gradually switching to PHP at some point.
>>> Will the above plan of execution be ok?
>> A transaction is a bunch of queries which you want to all get committed or
>> aborted together. The expensive step in Postgres is the COMMIT. Postgres does
>> an fsync which forces the data to go to disk (if you're using good hardware,
>> and don't have fsync=off). That takes from 5-15ms depending on how much data
>> and how fast your drives are.
>
>
>
>
> If I am reading this right, does this mean it is probably better to
> leave fsync as "fsync=off" on production machines? Also, is COMMIT
> automatic for my queries? In some minor testing I did (not scientific
> I did at all) some queries through Perl did not update the database at
> all. I had "fsync=off" in my conf file, and there was no COMMIT etc in
> my SQL, just plain SQL. So I am a bit confused. What's a good starting
> point?
>
[snip]
>
> So, again, in the conf file, is this what you recommend:
>
> fsync=off
I seriously doubt that's what he means.
"fsync=off" *is* faster than "fsync=on", but leaves your data at
risk in case of a hardware crash.
Turning it off during initial data load is quite common, though.
Just remember to turn it back on!!!
- --
Ron Johnson, Jr.
Jefferson LA USA
Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGwczGS9HxQb37XmcRAhUvAJ9LsQPvd6tQDp+/Mzh3jl8oPs4mHQCffjev
2uCJa3x0/NzUQBVmaJMcVR4=
=kVMU
-----END PGP SIGNATURE-----
