Finally upgrading to 9.6!
Where can I look to see (roughly) how much more RAM/CPU/disk needed when
moving from 8.4 and 9.2?
Thanks
--
World Peace Through Nuclear Pacification
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Ron Johnson <ron.l.johnson@cox.net> writes:
Where can I look to see (roughly) how much more RAM/CPU/disk needed when
moving from 8.4 and 9.2?
It's entirely possible you'll need *less*, as you'll be absorbing the
benefit of several years' worth of performance improvements. But this
is such a workload-dependent thing that there's no general answer.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 10/17/2017 11:17 AM, Tom Lane wrote:
Ron Johnson <ron.l.johnson@cox.net> writes:
Where can I look to see (roughly) how much more RAM/CPU/disk needed when
moving from 8.4 and 9.2?It's entirely possible you'll need *less*, as you'll be absorbing the
benefit of several years' worth of performance improvements. But this
is such a workload-dependent thing that there's no general answer.
XML stored in blobs (not sure whether text or bytea) and b-tree indexes.
--
World Peace Through Nuclear Pacification
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Import Notes
Reply to msg id not found: NgHR1w00Y2ozp4201gHSaV
On 10/18/2017 6:24 AM, Ron Johnson wrote:
On 10/17/2017 11:17 AM, Tom Lane wrote:
Ron Johnson <ron.l.johnson@cox.net> writes:
Where can I look to see (roughly) how much more RAM/CPU/disk needed
when
moving from 8.4 and 9.2?It's entirely possible you'll need *less*, as you'll be absorbing the
benefit of several years' worth of performance improvements. But this
is such a workload-dependent thing that there's no general answer.XML stored in blobs (not sure whether text or bytea) and b-tree indexes.
A bit off-topic here, but why upgrade to 9.6 when you can upgrade to 10.0?
Obviously you're not one to upgrade often so shouldn't you take
advantage of all of the new features and improvements when "finally" (to
use your own word) upgrading?
Igal Sapir
Lucee Core Developer
Lucee.org <http://lucee.org/>
On 18/10/2017 17:34, Igal @ Lucee.org wrote:
On 10/18/2017 6:24 AM, Ron Johnson wrote:
On 10/17/2017 11:17 AM, Tom Lane wrote:
Ron Johnson <ron.l.johnson@cox.net> writes:
Where can I look to see (roughly) how much more RAM/CPU/disk needed when
moving from 8.4 and 9.2?It's entirely possible you'll need *less*, as you'll be absorbing the
benefit of several years' worth of performance improvements. But this
is such a workload-dependent thing that there's no general answer.XML stored in blobs (not sure whether text or bytea) and b-tree indexes.
A bit off-topic here, but why upgrade to 9.6 when you can upgrade to 10.0?
Had the same question, we are moving from 9.3 -> 10.0 near the start of summer (I hope).
10.0's pg_upgrade supports 8.4 . One reason to upgrade in smaller steps is maybe to grasp the new changes / features better?
Obviously you're not one to upgrade often so shouldn't you take advantage of all of the new features and improvements when "finally" (to use your own word) upgrading?
Igal Sapir
Lucee Core Developer
Lucee.org <http://lucee.org/>
--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt
On 10/18/2017 09:34 AM, Igal @ Lucee.org wrote:
On 10/18/2017 6:24 AM, Ron Johnson wrote:
On 10/17/2017 11:17 AM, Tom Lane wrote:
Ron Johnson <ron.l.johnson@cox.net> writes:
Where can I look to see (roughly) how much more RAM/CPU/disk needed when
moving from 8.4 and 9.2?It's entirely possible you'll need *less*, as you'll be absorbing the
benefit of several years' worth of performance improvements. But this
is such a workload-dependent thing that there's no general answer.XML stored in blobs (not sure whether text or bytea) and b-tree indexes.
A bit off-topic here, but why upgrade to 9.6 when you can upgrade to 10.0?
Obviously you're not one to upgrade often so shouldn't you take advantage
of all of the new features and improvements when "finally" (to use your
own word) upgrading?
There's no way we're going to put an x.0.0 version into production.
--
World Peace Through Nuclear Pacification
Import Notes
Reply to msg id not found: P2cq1w03i1DF5NZ012csAH
On 10/18/2017 7:45 AM, Ron Johnson wrote:
On 10/18/2017 09:34 AM, Igal @ Lucee.org wrote:
A bit off-topic here, but why upgrade to 9.6 when you can upgrade to
10.0?There's no way we're going to put an x.0.0 version into production.
Then think of it as 9.7.0 but with an easier name to pronounce ;)
Igal Sapir
Lucee Core Developer
Lucee.org <http://lucee.org/>
On Wed, Oct 18, 2017 at 8:16 AM, Igal @ Lucee.org <igal@lucee.org> wrote:
On 10/18/2017 7:45 AM, Ron Johnson wrote:
On 10/18/2017 09:34 AM, Igal @ Lucee.org wrote:
A bit off-topic here, but why upgrade to 9.6 when you can upgrade to
10.0?There's no way we're going to put an x.0.0 version into production.
Then think of it as 9.7.0 but with an easier name to pronounce ;)
The OP likely intended to say "x.0" version; which a "[9.7].0" version is
just the same as a [10].0 version
The contributors do an excellent job but the reality of this community is
that a critical mass of people do not start seriously testing and using a
new version until it is officially released. The first couple of bug-fix
releases are thus, unfortunately, likely to be non-trivial as the masses
flex the system at scales and using workloads that were not known or
available to the developers. Its a balancing act for most and falling on
the side of waiting for a few point releases before promoting to production
is, I suspect, common.
David J.
On 10/18/2017 10:16 AM, Igal @ Lucee.org wrote:
On 10/18/2017 7:45 AM, Ron Johnson wrote:
On 10/18/2017 09:34 AM, Igal @ Lucee.org wrote:
A bit off-topic here, but why upgrade to 9.6 when you can upgrade to 10.0?
There's no way we're going to put an x.0.0 version into production.
Then think of it as 9.7.0 but with an easier name to pronounce ;)
No .0 is going into production...
--
World Peace Through Nuclear Pacification
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Import Notes
Reply to msg id not found: P3Jz1w00V1DF5NZ013K1xu
On Wed, Oct 18, 2017 at 11:46 AM, David G. Johnston <
david.g.johnston@gmail.com> wrote:
On Wed, Oct 18, 2017 at 8:16 AM, Igal @ Lucee.org <igal@lucee.org> wrote:
On 10/18/2017 7:45 AM, Ron Johnson wrote:
On 10/18/2017 09:34 AM, Igal @ Lucee.org wrote:
A bit off-topic here, but why upgrade to 9.6 when you can upgrade to
10.0?There's no way we're going to put an x.0.0 version into production.
Then think of it as 9.7.0 but with an easier name to pronounce ;)
The OP likely intended to say "x.0" version; which a "[9.7].0" version is
just the same as a [10].0 versionThe contributors do an excellent job but the reality of this community is
that a critical mass of people do not start seriously testing and using a
new version until it is officially released. The first couple of bug-fix
releases are thus, unfortunately, likely to be non-trivial as the masses
flex the system at scales and using workloads that were not known or
available to the developers. Its a balancing act for most and falling on
the side of waiting for a few point releases before promoting to production
is, I suspect, common.David J.
I support the policy of using caution with regards to new versions. They
are often thought of as "bleeding edge" for the reason described by David G
Johnston. The fact that PostgreSQL 10 was only released this month is
critical and therefore is should not be a production server. It should be
used as development, or QA, at best.
--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
On 10/18/2017 08:49 AM, Ron Johnson wrote:
On 10/18/2017 10:16 AM, Igal @ Lucee.org wrote:
On 10/18/2017 7:45 AM, Ron Johnson wrote:
On 10/18/2017 09:34 AM, Igal @ Lucee.org wrote:
A bit off-topic here, but why upgrade to 9.6 when you can upgrade to
10.0?There's no way we're going to put an x.0.0 version into production.
Then think of it as 9.7.0 but with an easier name to pronounce ;)
No .0 is going into production...
I am not sure why this is even a question. There are plenty of
businesses that can risk the deployment of a .0 release but there are
also *MANY THAT CAN NOT*. The proper way to do this is to have a staging
server running the .0 release that gets beaten on by the application for
a few months and reports anything back to the community they find.
JD
--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
PostgreSQL Centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://pgconf.us
***** Unless otherwise stated, opinions are my own. *****
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Wed, Oct 18, 2017 at 11:26 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
On 10/18/2017 08:49 AM, Ron Johnson wrote:
On 10/18/2017 10:16 AM, Igal @ Lucee.org wrote:
On 10/18/2017 7:45 AM, Ron Johnson wrote:
On 10/18/2017 09:34 AM, Igal @ Lucee.org wrote:
A bit off-topic here, but why upgrade to 9.6 when you can upgrade to
10.0?There's no way we're going to put an x.0.0 version into production.
Then think of it as 9.7.0 but with an easier name to pronounce ;)
No .0 is going into production...
I am not sure why this is even a question. There are plenty of businesses
that can risk the deployment of a .0 release but there are also *MANY THAT
CAN NOT*. The proper way to do this is to have a staging server running the
.0 release that gets beaten on by the application for a few months and
reports anything back to the community they find.
In a past job I would routinely setup a slony slave running the new
version to check to make sure the new version wouldn't choke on the
data in the master etc, then start using it as a read slave after a
few months to make sure the app got along with it as a read only
source, then finally look at promoting it to master, with the option
to unpromote it should things explode. Minimal downtime for upgrades
AND a path back to the old version quickly if needed.
All while having setup dev and stage servers ahead of time to get
beaten on of course.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 10/18/2017 05:57 PM, Melvin Davidson wrote:
On Wed, Oct 18, 2017 at 11:46 AM, David G. Johnston
<david.g.johnston@gmail.com <mailto:david.g.johnston@gmail.com>> wrote:The contributors do an excellent job but the reality of this
community is that a critical mass of people do not start seriously
testing and using a new version until it is officially released.
The first couple of bug-fix releases are thus, unfortunately, likely
to be non-trivial as the masses flex the system at scales and using
workloads that were not known or available to the developers. Its a
balancing act for most and falling on the side of waiting for a few
point releases before promoting to production is, I suspect, common.I support the policy of using caution with regards to new versions. They
are often thought of as "bleeding edge" for the reason described by
David G Johnston. The fact that PostgreSQL 10 was only released this
month is critical and therefore is should not be a production server. It
should be used as development, or QA, at best.
No, the Betas and RC should have been used in development and QA.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Wed, Oct 18, 2017 at 1:08 PM, Vik Fearing <vik.fearing@2ndquadrant.com>
wrote:
On 10/18/2017 05:57 PM, Melvin Davidson wrote:
I support the policy of using caution with regards to new versions. They
are often thought of as "bleeding edge" for the reason described by
David G Johnston. The fact that PostgreSQL 10 was only released this
month is critical and therefore is should not be a production server. It
should be used as development, or QA, at best.No, the Betas and RC should have been used in development and QA.
I disagree with this. It isn't my company's business to test the Postgres
software in development, as much as it would be needed and appreciated by
the community. We're testing our own applications and processes, and this
should be done with a "stable" product, more or less. So I'd only ever
think to have them use an official release versus a beta or release
candidate.
That said, count me in the same camp with the "Never .0" folks. I'm
planning a mass upgrade to 9.6 soon as well and the question was raised as
to whether or not to go right to 10.0, and I quickly put that down. Oracle
DBAs have a similar rule of thumb with anything less than .2 (Oracle starts
at .1).
Don.
--
Don Seiler
www.seiler.us
On Wednesday, October 18, 2017, Joshua D. Drake <jd@commandprompt.com>
wrote:
I am not sure why this is even a question. There are plenty of businesses
that can risk the deployment of a .0 release but there are also *MANY THAT
CAN NOT*. The proper way to do this is to have a staging server running the
.0 release that gets beaten on by the application for a few months and
reports anything back to the community they find.
The continuum goes from having a staging server follow master/HEAD to
upgrading one version once a year as the earliest supported release gets
de-supported. The closer to the first position you are contributing back
to the community and also the more quickly you can benefit from the new
features and enhancements each new release brings.
David J.
On 10/18/2017 11:17 AM, Don Seiler wrote:
On Wed, Oct 18, 2017 at 1:08 PM, Vik Fearing
<vik.fearing@2ndquadrant.com <mailto:vik.fearing@2ndquadrant.com>> wrote:On 10/18/2017 05:57 PM, Melvin Davidson wrote:
I support the policy of using caution with regards to new versions. They
are often thought of as "bleeding edge" for the reason described by
David G Johnston. The fact that PostgreSQL 10 was only released this
month is critical and therefore is should not be a production server. It
should be used as development, or QA, at best.No, the Betas and RC should have been used in development and QA.
I disagree with this. It isn't my company's business to test the
Postgres software in development, as much as it would be needed and
appreciated by the community.
Exactly.
JD
--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
PostgreSQL Centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://pgconf.us
***** Unless otherwise stated, opinions are my own. *****
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 10/18/2017 08:17 PM, Don Seiler wrote:
On Wed, Oct 18, 2017 at 1:08 PM, Vik Fearing
<vik.fearing@2ndquadrant.com <mailto:vik.fearing@2ndquadrant.com>> wrote:On 10/18/2017 05:57 PM, Melvin Davidson wrote:
I support the policy of using caution with regards to new versions. They
are often thought of as "bleeding edge" for the reason described by
David G Johnston. The fact that PostgreSQL 10 was only released this
month is critical and therefore is should not be a production server. It
should be used as development, or QA, at best.No, the Betas and RC should have been used in development and QA.
I disagree with this. It isn't my company's business to test the
Postgres software in development, as much as it would be needed and
appreciated by the community.
Yeah, let others do it for you! Great attitude.
We're testing our own applications and
processes, and this should be done with a "stable" product, more or
less. So I'd only ever think to have them use an official release versus
a beta or release candidate.
And how do you think the product becomes stable? By magic?
That said, count me in the same camp with the "Never .0" folks.
Yes, I gathered that.
I'm planning a mass upgrade to 9.6 soon as well and the question was raised
as to whether or not to go right to 10.0, and I quickly put that down.
Right, because when you say "official release versus a beta or release
candidate", you don't actually mean it.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Wed, Oct 18, 2017 at 4:17 PM, Vik Fearing <vik.fearing@2ndquadrant.com>
wrote:
On 10/18/2017 08:17 PM, Don Seiler wrote:
I disagree with this. It isn't my company's business to test the
Postgres software in development, as much as it would be needed and
appreciated by the community.Yeah, let others do it for you! Great attitude.
It's a realistic, practical attitude. I'm sorry that not every company
wants to offer the resources to contribute back to the community as much as
you want. But it's foolish to expect a company to perform their development
lifecycle against betas and RCs. They have their own products to worry
about. A gallant few may let their DBAs do some sandbox testing to
contribute time back to the community, but you can't expect them to.
I'm planning a mass upgrade to 9.6 soon as well and the question was
raised
as to whether or not to go right to 10.0, and I quickly put that down.
Right, because when you say "official release versus a beta or release
candidate", you don't actually mean it.
I don't even know what you mean here. You're responding like I ran over
your dog and it's quite ridiculous.
Plain and simple, I wouldn't expect any DBA responsible for production
databases to run on a new major release, regardless of platform/vendor.
It's asking for a headache and maybe a few noisy pager nights. It doesn't
matter how much faith I have in the Postgres contributors/developers, I
have a responsibility to my employer to keep their database platforms up
and running. That is first and foremost. I'm sure if I found myself with
time to spare, I'll test upgrading a prod clone to 10 and asking some devs
to run it through its paces, but spare time is a luxury that you can't just
expect people to have.
--
Don Seiler
www.seiler.us
On Wed, Oct 18, 2017 at 2:34 PM, Don Seiler <don@seiler.us> wrote:
On Wed, Oct 18, 2017 at 4:17 PM, Vik Fearing <vik.fearing@2ndquadrant.com>
wrote:On 10/18/2017 08:17 PM, Don Seiler wrote:
I disagree with this. It isn't my company's business to test the
Postgres software in development, as much as it would be needed and
appreciated by the community.Yeah, let others do it for you! Great attitude.
It's a realistic, practical attitude. I'm sorry that not every company
wants to offer the resources to contribute back to the community as much as
you want. But it's foolish to expect a company to perform their development
lifecycle against betas and RCs. They have their own products to worry
about. A gallant few may let their DBAs do some sandbox testing to
contribute time back to the community, but you can't expect them to.
Both sides have made their point here - any more opinions or
justifications are going to just end up devolving into commentary that is
unacceptable on these lists. The community benefits from people who do
more than just run production servers while the business world has limited
resources to do not directly business related activities. I feel that
those familiar with those dynamics are not surprised that someone would
choose to upgrade to 9.6.5 now since the 10.x series is still .0
If someone wants to espouse the business benefits of running pre-release
versions in staging environments against stable business code please start
a new thread focused on the "process" and not the "people".
David J.
On 18 October 2017 at 17:17, Vik Fearing <vik.fearing@2ndquadrant.com> wrote:
On 10/18/2017 08:17 PM, Don Seiler wrote:
On Wed, Oct 18, 2017 at 1:08 PM, Vik Fearing
<vik.fearing@2ndquadrant.com <mailto:vik.fearing@2ndquadrant.com>> wrote:On 10/18/2017 05:57 PM, Melvin Davidson wrote:
I support the policy of using caution with regards to new versions. They
are often thought of as "bleeding edge" for the reason described by
David G Johnston. The fact that PostgreSQL 10 was only released this
month is critical and therefore is should not be a production server. It
should be used as development, or QA, at best.No, the Betas and RC should have been used in development and QA.
I disagree with this. It isn't my company's business to test the
Postgres software in development, as much as it would be needed and
appreciated by the community.Yeah, let others do it for you! Great attitude.
We need *some* people doing this; I don't think beating people up for
not being "beta testers" is terribly friendly.
The one thing I'd want to poke at is "don't avoid 10.0 simply because of
there being a 0 there."
If someone would have declined to use 9.7.0, considering that "too beta,"
then it's reasonable to decline 10.0, as that is a reasonably similar policy.
On the other hand, if you'd have accepted 9.7.0, and are declining
10.0.0 just "because too many 0's", that's not so right, and I'd want
to encourage considering it.
We're testing our own applications and
processes, and this should be done with a "stable" product, more or
less. So I'd only ever think to have them use an official release versus
a beta or release candidate.And how do you think the product becomes stable? By magic?
That said, count me in the same camp with the "Never .0" folks.
Yes, I gathered that.
I'm planning a mass upgrade to 9.6 soon as well and the question was raised
as to whether or not to go right to 10.0, and I quickly put that down.Right, because when you say "official release versus a beta or release
candidate", you don't actually mean it.
I'm inclined to wait a bit on 10.0, not because I expect it to be
particularly problematic, but because it's fairly reasonable to expect
other things to not be ready instantaneously. And that includes some
things one might reasonably hope for.
- We have a Slony release that supports 10.0, but were there to be
some lag, some people might be inclined to wait for that.
- The same applies to any number of interesting third party
applications or libraries.
- Might want to wait until binaries are included in Debian Stable
or some favored Red Hat or CentOS release or such.
There's plenty of reasonable arguments for waiting a bit.
I'd contend that "otta be running 10.0 in Dev/QA" isn't so
obviously apropos. I tend to have my workstation running
"bleeding edge" versions of things so that I notice
sharp edges early, but what we always want to have most
folks running are the *same* versions in Dev+QA+Prod,
so that there aren't unexpected differences.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
