Обсуждение: [GENERAL] 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
On 10/18/2017 6:24 AM, Ron Johnson wrote:
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?
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 whenIt's entirely possible you'll need *less*, as you'll be absorbing the
moving from 8.4 and 9.2?
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
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 whenIt's entirely possible you'll need *less*, as you'll be absorbing the
moving from 8.4 and 9.2?
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
-- 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 whenIt's entirely possible you'll need *less*, as you'll be absorbing the
moving from 8.4 and 9.2?
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
On 10/18/2017 7:45 AM, Ron Johnson wrote:
Then think of it as 9.7.0 but with an easier name to pronounce ;)
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
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
On Wed, Oct 18, 2017 at 11:46 AM, David G. Johnston <david.g.johnston@gmail.com> 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.
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.
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).
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
www.seiler.us
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
On 19/10/17 10:34, Don Seiler wrote: > On Wed, Oct 18, 2017 at 4:17 PM, Vik Fearing > <vik.fearing@2ndquadrant.com <mailto: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. Actually that attitude is short sighted, as your company might trigger problems no one else has (or at least not prepared to report bugs on). Surely you want such bugs fixed BEFORE you use pg in production??? It is also likely to take time to know how best to use the changes in a newer version of pg for your database in your operational environment. So it is in the best self interests of your company to to test development versions of pg prior to final release. Helping others, in this context, is a more sophisticated form of selfishness than you display at the moment. Cheers, Gavin > > 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 <http://www.seiler.us> -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general