Given a system with 32 cores, an SSD SAN with 48x drives, and 2x 8Gbps
paths from the server to the SAN, what would be a good starting point
to set effective_io_concurrency? I currently have it set to 32, but I
kind of feel like the right setting would be "2" since we have two
paths. We don't oft
wrote:
> On Fri, May 10, 2013 at 11:11 AM, Evan D. Hoffman
> wrote:
> > Not sure of your space requirements, but I'd think a RAID 10 of 8x or
> more
> > Samsung 840 Pro 256/512 GB would be the best value. Using a simple
> mirror
> > won't get you the relia
Not sure of your space requirements, but I'd think a RAID 10 of 8x or more
Samsung 840 Pro 256/512 GB would be the best value. Using a simple mirror
won't get you the reliability that you want since heavy writing will burn
the drives out over time, and if you're writing the exact same content to
b
db=#
On Wed, May 8, 2013 at 4:12 PM, Igor Neyman wrote:
>
>
>> -Original Message-
>> From: Evan D. Hoffman [mailto:evandhoff...@gmail.com]
>> Sent: Wednesday, May 08, 2013 3:35 PM
>> To: Igor Neyman
>> Subject: Re: [GENERAL] pg_upgrade fails, "mism
I've tried several times to upgrade a test database (with real data,
~500 GB) from 9.1 to 9.2 using pg_upgrade and every time it fails with
the same error. I've tried a few different options to pg_upgrade but
always the same result. Nothing really useful has turned up in
Google. Any thoughts? C
Ok. Thanks for your help.
On Oct 11, 2012, at 3:31 PM, Tom Lane wrote:
> "Evan D. Hoffman" writes:
>> Because we have both 9.0 and 9.1 running, and a query that succeeds
>> under 9.1 was failing under 9.0. Can I assume the answer then is
>> "no"?
>
Because we have both 9.0 and 9.1 running, and a query that succeeds
under 9.1 was failing under 9.0. Can I assume the answer then is
"no"?
On Thu, Oct 11, 2012 at 2:38 PM, Tom Lane wrote:
> "Evan D. Hoffman" writes:
>> Is there any way to disable the guessing of
Is there any way to disable the guessing of missing columns in a
group-by (the feature added in 9.1)? I haven't found any option but I
might not be searching for the right thing.
http://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.1#SQL_and_PL.2FPgSQL_features
--
Sent via pgsql-genera
config file as described in that doc resolved it.
On Jun 13, 2012, at 10:26 PM, Bruce Momjian wrote:
> On Wed, Jun 13, 2012 at 11:19:41AM -0400, Evan D. Hoffman wrote:
>> I'm trying to upgrade Postgres 9.0 to 9.1 with pg_upgrade. Both
>> versions are installed fr
how it determines whether or not the server was
started).
On Wed, Jun 13, 2012 at 10:49 PM, Bruce Momjian wrote:
> On Wed, Jun 13, 2012 at 10:41:37PM -0400, Evan D. Hoffman wrote:
>> Actually I found the solution right after I sent that email (of
>> course):
>>
>>
I'm trying to upgrade Postgres 9.0 to 9.1 with pg_upgrade. Both
versions are installed from the PGDG Yum repo:
-bash-4.1$ /usr/pgsql-9.0/bin/postgres -V
postgres (PostgreSQL) 9.0.8
-bash-4.1$ /usr/pgsql-9.1/bin/postgres -V
postgres (PostgreSQL) 9.1.4
I can successfully start and connect to both
I'm planning to migrate our pg db to a new machine in the next couple
of weeks. The current DB has 32 GB memory; the new one will have 96
GB. It's going to be Postgres 8.2.x (we're planning to upgrade to 8.4
as part of another project) running on CentOS 5.4 or 5.5. I know the
old rule of thumb t
Thanks, Brian & Jaime. Regarding Slony, would that allow for
migration to a new version as well - i.e. moving from 8.2 on the old
machine to 8.4 on the new machine via Slony with minimal downtime?
The Slony method is one I hadn't considered. Since our database is so
large, even a direct file cop
13 matches
Mail list logo
