On Thu, 17 Feb 2005, Magnus Hagander wrote:
Hi,
looking for the way how to increase performance at Windows XP
box, I found the parameters
#fsync = true # turns forced
synchronization on or off
#wal_sync_method = fsync# the default varies across platforms:
On Thu, 17 Feb 2005, Christopher Kings-Lynne wrote:
The general question is - does PostgreSQL really need fsync? I suppose it
is a question for design, not platform-specific one. It sounds like only
one scenario, when fsync is useful, is to interprocess communication via
open file. But PostgreSQL
Hi,
looking for the way how to increase performance at Windows XP box, I found
the parameters
#fsync = true # turns forced synchronization on or off
#wal_sync_method = fsync# the default varies across platforms:
# fsync, fdatasync,
I've tested the performance of 8.0.1 at my dual-boot notebook (Linux and
Windows XP).
I installed 8.0.1 for Linux and Windows XP, and run pgbench -c 1 -t 1000
Under Linux (kernel 2.6.10) I got about 800 tps, and under Windows XP -
about 20-24 tps.
Next I switched off virtual memory under Windows
On Tue, 15 Feb 2005, Magnus Hagander wrote:
I've tested the performance of 8.0.1 at my dual-boot notebook
(Linux and Windows XP).
I installed 8.0.1 for Linux and Windows XP, and run pgbench
-c 1 -t 1000 Under Linux (kernel 2.6.10) I got about 800 tps,
and under Windows XP - about 20-24 tps.
Next I
On Tue, 15 Feb 2005, Matthew T. O'Connor wrote:
Magnus Hagander wrote:
Also, didn't someone recently report some very significant performance
differences Windows networking QoS (Quality of Service) installed? You
might try that.
It's unlikely. Postmaster listens loopback, AFAIK loopback does
On Tue, 15 Feb 2005, Magnus Hagander wrote:
Run:
hdparm -I /dev/hda
If you get a line like:
Commands/features:
Enabled Supported:
*READ BUFFER cmd
*WRITE BUFFER cmd
*Host Protected Area feature set
*Look-ahead
*Write
On Wed, 3 Dec 2003, Stephan Szabo wrote:
The locale settings depend on LC_* at initdb time only. When the
postmaster starts it sets the locale based on the stored values from
initdb, not on the current environment.
With an SQL_ASCII database being accessed from a client with
client_encoding
On Fri, 28 Nov 2003, Tom Lane wrote:
E.Rodichev [EMAIL PROTECTED] writes:
/e:2createdb test
test | er | SQL_ASCII - Incorrect!
(3 rows)
Let's note than the last line is in fact completely incorrect.
What's incorrect about it? You didn't ask for any other encoding
On Wed, 3 Dec 2003, Stephan Szabo wrote:
On Wed, 3 Dec 2003, E.Rodichev wrote:
On Fri, 28 Nov 2003, Tom Lane wrote:
E.Rodichev [EMAIL PROTECTED] writes:
/e:2createdb test
test | er | SQL_ASCII - Incorrect!
(3 rows)
Let's note than the last line
On Wed, 3 Dec 2003, Alvaro Herrera wrote:
On Wed, Dec 03, 2003 at 11:42:34PM +0300, E.Rodichev wrote:
On Wed, 3 Dec 2003, Stephan Szabo wrote:
No, it isn't. As far as PostgreSQL is concerned the database is SQL_ASCII
since you didn't override the default encoding at initdb time
On Wed, 3 Dec 2003, Andrew Dunstan wrote:
Encoding and collation order are two different things. LC_* settings
have no effect on encoding.
see http://www.postgresql.org/docs/current/static/charset.html
I am trying to point out to reverse dependency:
encoding (1) has effect on LC_* settings
On Wed, 3 Dec 2003, Stephan Szabo wrote:
Only the locale settings at initdb time matter. Changing the LC_* later
is not going to change what the database does. Encoding and locale are
separate (but related) and it is your responsibility to make sure the
choices are consistent. If you do not
Hi,
I just noticed some incorrect behaviour for postgresql-7.4 related
to locale.
After installing 7.4 I created database completely from scratch
with cyrillic locale:
su postgres
export LC_CTYPE=ru_RU.KOI8-R
export LC_COLLATE=ru_RU.KOI8-R
/usr/local/pgsql/bin/initdb -D /db2/pgdata
14 matches
Mail list logo
