From: | Tom Wilcox <hungrytom(at)googlemail(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Fwd: Out of Memory and Configuration Problems (Big Computer) |
Date: | 2010-06-02 14:39:52 |
Message-ID: | AANLkTilJcl5TD7XYcT5tTVjWiUL1e8aaI3QVvygHE8Hd@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Stephen,
You're a legend! That is exactly the answer I needed to hear from someone
who actually knows the score. I am now powering on with Plan B: Postgres64
on Linux64.
After relentless searching I have become fairly convinced that a stable
release of 64-bit postgres for Windows doesn't exist yet. (I welcome anyone
to show me otherwise). Since I am committed to postgres (already written the
code, it works just not quickly), I will have to change my OS.
However, if these performance limitations on Windows were apparent to me
from the start, I probably would have chosen MS SQL Server over Postgres
(less pain to get the gain). Perhaps this is an argument in favour of 64-bit
Windows port to be added to this list:
http://wiki.postgresql.org/wiki/64bit_Windows_port
Thanks again for all your help.
Tom
On 2 June 2010 15:27, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Tom,
>
> * Tom Wilcox (hungrytom(at)googlemail(dot)com) wrote:
> > The impression I was getting from Magnus Hagander's blog was that a
> 32-bit
> > version of Postgres could make use of >4Gb RAM when running on 64-bit
> > Windows due to the way PG passes on the responsibility for caching onto
> the
> > OS.. Is this definitely not the case then?
>
> Eh, sure, the data will be cache'd in the Windows OS, so more data will
> be in memory, but you're never going to be able to use more than 4G for
> any actual *processing*, like sorting, doing hash joins, having data in
> shared buffers (to avoid having to go back to the OS and doing a system
> call to get the data from the OS's cache..).
>
> Not only that, but the shared_buffers are in *every* backend, so while
> you'll only use 512MB for shared_buffers total, each backend will only
> have 3.5G (or so) of memory to do 'other stuff'.
>
> On a box with 16GB that's doing alot of relatively small activities
> (OLTP type stuff), PG will work "alright". On a box with 96G with
> terrabytes of data where you want to do data warehousing kind of work,
> running a 32bit version of PG is going to suck.
>
> Thanks,
>
> Stephen
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkwGalUACgkQrzgMPqB3kigWugCfY411is3uy3grP6lSH3P+neaf
> evYAn2vY8/V3GntpQA9Q434U79+GThSW
> =ar57
> -----END PGP SIGNATURE-----
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Janning | 2010-06-02 14:41:55 | replanning prepared Statements |
Previous Message | Tom Lane | 2010-06-02 14:36:41 | Re: Statement Pooling |