Обсуждение: postgres on Windows

Поиск
Список
Период
Сортировка

postgres on Windows

От
"Mark Steben"
Дата:

Our 8.3.7 production environment is run on Linux operating systems.  We do, however

Have our developers who keep a local copy of the database on their windows XP machines.

One such developer has asked my help in configuring postgresql.conf to optimize his performance.

 

The 8.3 documentation is very informative about setting Linux SYS 5 parameters and

giving insight to postgres memory consumption parms.  I can’t seem to find a lot of guidelines

for Windows performance.

 

The developer has 3 GB of ram and 130 GB hard drive.  Any insight, guidelines,

Or any reference I can be pointed to would be most appreciated.

 

Thank you,

 

 

 

Mark StebenDatabase Administrator

@utoRevenue®-"Join the Revenue-tion"
95 Ashley Ave., West Springfield, Ma
413-243-4800 x1512 (Phone) 
│ 413.732-1824 (Fax)
@utoRevenue is a registered trademark and a division of Dominion Enterprises

 

Re: postgres on Windows

От
Scott Marlowe
Дата:
2009/12/28 Mark Steben <msteben@autorevenue.com>:
> Our 8.3.7 production environment is run on Linux operating systems.  We do,
> however
>
> Have our developers who keep a local copy of the database on their windows
> XP machines.
>
> One such developer has asked my help in configuring postgresql.conf to
> optimize his performance.
>
> The 8.3 documentation is very informative about setting Linux SYS 5
> parameters and
> giving insight to postgres memory consumption parms.  I can’t seem to find a
> lot of guidelines
> for Windows performance.
>
> The developer has 3 GB of ram and 130 GB hard drive.  Any insight,
> guidelines,
> Or any reference I can be pointed to would be most appreciated.

Tuning on windows is similar to running on linux, except that
increasing shared_buffer memory in windows shows fewer returns, and
only a few hundred meg is usually plenty.  Unless you're actively
working on sets larger than shared_buffers, don't crank it way up.

Look at turning up work_mem and maintenance_work_mem.
Lower random_page_cost and raise effective_cache_size, especially if
the dataset on the dev database will fit easily into memory.

If the data on the workstation isn't important, you can try turning
off fsync (warning, your data WILL get corrupted and lost if / when
windows crashes someday)  Or get most of the gain by turning off
synchronous_commit which makes it faster but keeps your data from
getting corrupted should the machine shut down unexpectedly.