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 u
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:
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, open_sync
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 cache
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 n
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
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 (a
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_enc
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
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_* settin
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
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:2>createdb test
> > >
> &g
On Fri, 28 Nov 2003, Tom Lane wrote:
> "E.Rodichev" <[EMAIL PROTECTED]> writes:
> > /e:2>createdb test
>
> > test | er | SQL_ASCII <- Incorrect!
> > (3 rows)
>
> > Let's note than the last line is in fact completely i
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
/usr/local/pg
14 matches
Mail list logo
