| From: | "Scott Marlowe" <smarlowe(at)qwest(dot)net> |
|---|---|
| To: | "Andy B" <abhousehuntRE-M--O--V-E(at)blueyonder(dot)co(dot)uk> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Enough RAM for entire Database.. cost aside, is this |
| Date: | 2004-07-09 22:46:47 |
| Message-ID: | 1089413207.19270.12.camel@localhost.localdomain |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Thu, 2004-07-08 at 13:19, Andy B wrote:
> Ok, this is very interesting. I had assumed that PG's cache already built up
> such in memory structures from the data it gets off disk (aka OS buffer, God
> willing).
>
> Which particular DB's out there would be worth checking out for my
> particular 'all in RAM scenario'?
>
> (Though I need geographical index support or the ability to add my
> own...that was the thing that originally made me look at PG - that and
> having tried to use Mysql)
You're going about this the wrong way. Build a reasonable large test
database and see how postgresql does. Examining the underlying tech in
a database is all well and good for pointers, but until you really
benchmark it with realistic load, you don't know what it will actually
do. You're gonna buy a big honkin box anyway, so after you get it, test
the different engines to see what they can do.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2004-07-10 01:49:54 | Re: [HACKERS] PgSQL 7.4.2 - NaN on Tru64 UNIX |
| Previous Message | Dann Corbit | 2004-07-09 22:11:27 | Re: number of pgsql connections established. |