Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eXpjV-0000hs-3d for pgsql-docs@arkaria.postgresql.org; Sat, 06 Jan 2018 14:46:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eXpjU-0006fB-NA for pgsql-docs@arkaria.postgresql.org; Sat, 06 Jan 2018 14:46:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eXpjU-0006f1-HW for pgsql-docs@lists.postgresql.org; Sat, 06 Jan 2018 14:46:00 +0000 Received: from mail-qk0-x234.google.com ([2607:f8b0:400d:c09::234]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eXpjM-0002Ig-Mn for pgsql-docs@postgresql.org; Sat, 06 Jan 2018 14:45:59 +0000 Received: by mail-qk0-x234.google.com with SMTP id v188so9336941qkh.11 for ; Sat, 06 Jan 2018 06:45:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hagander-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dJGma2CM2S+2gGVM9nAcXODoIHB6kWYYDr60Q4yumJI=; b=X61IR/KgB49tQQvfnBHq/7B1YGpJpOHO2jldUCoGXomQQL43jbUgqZtdTZ7w8te6GK CZjckrn57OoMDE7MJ737X0osUWbtD6A7JIpitoqc7y4xFK/6DMpGBoZQljD2xuL9kerA 0qi1wIx/Iq2iLgxVKyhF0qyhZQ1UbPAfhCkDPwxdmABwocj9mPa9A2FC7Co5de0ITRjL iMb/6EQPpQYoMWVrUS9FDPXfJQKJ4aMQr0Ca4xgosj0kVXeG1s7tue7XFm522kYU9Od8 WZQmHgaxkxVD7/dbwOvJeuvenQcTwlyH4P4o/pC60hpS/oHnPTUZXGa/ElBO5rkdKoN0 WbkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dJGma2CM2S+2gGVM9nAcXODoIHB6kWYYDr60Q4yumJI=; b=TylT6KUaW538r9SSXj2nxCT6Qjmp6Kb33Gu2VUmY0sNHnAmbOoLL7jPae2MN6GxheE zOBP5aMMpNDDcU9JZYFgEvCWEVdz3tZi6nkR4Eoftk2XzOpQ3KNJEggdhKkt07SuPAL8 M0ORXaGIJDqHi0NfRTD16r7vDAAda9f9g8/d9kyxXK/rAFm+QbBAK/y4wgizMxeuIi9j NKXp33wwpVNz/PoUv9hQG7t0mocmQRHOphRjvFRIoZce3zr80+222UwVqeTWYYvBlX4y QSNv3+rceRpoq8JfBmvSqZYFatXIa3akUla4w1n0XNpMGO2OE9PAQp95iNecUz2OD7ra sfQQ== X-Gm-Message-State: AKwxyte97b48IxKI1NRNVRbd+iyK0i/6M8KabRugeuJmW70AgG1POzZu GdjBx/lnc7GoAIXQWbHoZw8v2XyfR+L2U6TtCayTrA== X-Google-Smtp-Source: ACJfBottSWc7vRUuCrZQ+u3NnyA+opXDOZK9e48+tTYJmJ7dVz7yAoHcrLTZeO5sPzTaMTDT/rNx2He38yv/RW8E4Uc= X-Received: by 10.55.249.8 with SMTP id l8mr8148738qkj.86.1515249950062; Sat, 06 Jan 2018 06:45:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.52.130 with HTTP; Sat, 6 Jan 2018 06:45:49 -0800 (PST) In-Reply-To: <630D932F-79D5-41C8-9007-06E919BB910A@postgresql.org> References: <4fe11dc1b660433594624b280b8ad832@SC58MEXGP036.CORP.CHARTERCOM.com> <3d7cd4673a80438798ad20b83411e3ca@SC58MEXGP001.CORP.CHARTERCOM.com> <1646547df04f4555a548ad7815208d5f@SC58MEXGP036.CORP.CHARTERCOM.com> <20180105175438.GO2416@tamriel.snowman.net> <68e5e2554e2240c6a22bd384fa7c9659@SC58MEXGP036.CORP.CHARTERCOM.com> <20180105180019.GP2416@tamriel.snowman.net> <7F963E79-CF4F-4E93-AA46-36E1817332D0@blighty.com> <630D932F-79D5-41C8-9007-06E919BB910A@postgresql.org> From: Magnus Hagander Date: Sat, 6 Jan 2018 15:45:49 +0100 Message-ID: Subject: Re: Is this still accurate? To: "Jonathan S. Katz" Cc: Steve Atkins , "pgsql-docs@postgresql.org" Content-Type: multipart/alternative; boundary="089e082cdf78050ed705621c9f2c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --089e082cdf78050ed705621c9f2c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 5, 2018 at 8:09 PM, Jonathan S. Katz wrote: > Hi, > > On Jan 5, 2018, at 1:33 PM, Steve Atkins wrote: > > > On Jan 5, 2018, at 10:00 AM, Stephen Frost wrote: > > Greetings, > > * Moser, Glen G (Glen.Moser@charter.com) wrote: > > That's really the gist of the concern from a team member of mine. Not > that the 4TB number is wrong but that it could be misleading to assume th= at > 4TB is some sort of upper bound. > > That's how this concern was relayed to me and I am just following up. > > > Well, saying 'in excess of' is pretty clear, but I don't think the > sentence is really adding much either, so perhaps we should just remove > it. > > > It's been useful a few times to reassure people that we can handle "large= " > databases operationally, rather than just having large theoretical limits= . > > Updating it would be great, or wrapping a little more verbiage around the > 4TB number, but a mild -1 on removing it altogether. > > > Here is a proposed patch that updates the wording: > > "There are active PostgreSQL instances in production environments that > manage many terabytes of data, as well as clusters managing petabytes.=E2= =80=9D > > The idea is that it gives a sense of scope for how big instances/clusters > can run without fixing people on a number. People can draw their own > conclusions from the hard limits further down the page. > > +1. --=20 Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/ --089e082cdf78050ed705621c9f2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jan 5, 2018 at 8:09 PM, Jonathan S. Katz <= jkatz@postgresql.= org> wrote:
Hi,

On Jan = 5, 2018, at 1:33 PM, Steve Atkins <steve@blighty.com> wrote:


On Jan 5, 2018, at 10:00 AM, Stephen Frost <sfrost@snowman.net> wrote:<= br>
Greetings,

* Moser, Glen G (Glen.Moser@charter.com) wrote:
That's really the gist of the concern from a team membe= r of mine.=C2=A0 Not that the 4TB number is wrong but that it could be misl= eading to assume that 4TB is some sort of upper bound.

That's ho= w this concern was relayed to me and I am just following up.

Well, saying 'in excess of' is pretty clear, but I don't = think the
sentence is really adding much either, so perhaps we should ju= st remove
it.

It's been useful a few times to re= assure people that we can handle "large"
databases operational= ly, rather than just having large theoretical limits.

Updating it wo= uld be great, or wrapping a little more verbiage around the
4TB number, = but a mild -1 on removing it altogether.

Here is= a proposed patch that updates the wording:

"Th= ere are active PostgreSQL instances in production environments that manage = many terabytes of data, as well as clusters managing petabytes.=E2=80=9D
The idea is that it gives a sense of scope for how big instances/clust= ers can run without fixing people on a number.=C2=A0 People can draw their = own conclusions from the hard limits further down the page.

+1.
=C2=A0


--=
=C2=A0Magnus Hagander
=C2=A0Me: https://www.hagander.net/
=C2=A0Wor= k: https://www= .redpill-linpro.com/
--089e082cdf78050ed705621c9f2c--