I am currently working on a patch to 7.2 that will allow data/indexes to
be in different locations. I am also looking at replacing the current
LOCATION code with a table driven (pg_locations) that will allow not
only the default data/indexes locations to be set but also each
table/index to have its own location. The first part is finished. I
will be making a patch tomorrow after some more testing. On my app
(about 400G of table data and 350G of index data) it really makes a
difference...
Jim
> >> - Hardware: dual / quad Intel class
> >
> >OK, but remember I/O is key for databases. The more spindles the
> >better. See my performance article on techdocs.
>
> >> - OS: Prolly FreeBSD (FFS is your friend (what with syncs and all)
and it
> >> can do multi proc support
>
> >I would recommend soft updates be enabled.
>
> Good points.
>
> >> - Disk: SCSI Raid 1+0
> >
> >Not sure about that. Is that optimal for I/O?
>
> >From my experience it is. As long as you have a raid controler that
> can do 2 level RAID abstraction. First you need mirrored pairs and
> then you stripe over them. It costs a lot in disk, but is stupid
fast
> with the right raid controller. With some Suns / FC / EMC, we were
> getting ~100M/s+ with that setup for our Oracle server.
>
> >> - Ram: Not really sure here. Is there math somewhere for ram
needs for
> >> pgsql? I imagine is has something to do with # connections, db
size,
> >> etc.
> >
> >Again, see article.
>
> Thanks.
>
>
>
----------------------------------------------------------------------------
> b. palmer, bpalmer@crimelabs.net
pgp:crimelabs.net/bpalmer.pgp5
>
>
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
majordomo@postgresql.org
>
>