Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eXt07-0005Dm-KJ for pgsql-docs@arkaria.postgresql.org; Sat, 06 Jan 2018 18:15:23 +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 1eXt06-0006Mp-Ea for pgsql-docs@arkaria.postgresql.org; Sat, 06 Jan 2018 18:15:22 +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 1eXt06-0006MY-5B for pgsql-docs@lists.postgresql.org; Sat, 06 Jan 2018 18:15:22 +0000 Received: from mail-ot0-x243.google.com ([2607:f8b0:4003:c0f::243]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eXt02-0006kR-6y for pgsql-docs@postgresql.org; Sat, 06 Jan 2018 18:15:21 +0000 Received: by mail-ot0-x243.google.com with SMTP id x15so6376901ote.0 for ; Sat, 06 Jan 2018 10:15:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CGxG0/j7xC0/a4huNgmAxOnwb1bGe2VtlWCfROb5YG8=; b=SVwNRxkyiia+sCYnCIxkycxypXomWfV+PtmEc/9RduUgnrEJFCwJocDOWTkpVXCmQ3 rEV9J4GunQoPxadRap9+aDXryQ4BgTyxD4rJ690tXV7Pd8ujO0mZ7Qk4ExK0zmgVyYgU 3cess9F3gRoIIRdHOMKGMETvKd9jfxWOmZ1KiBZU0U9Af0EqNGvMpIc7TYGa1LeUmrUH +EMLR57hKzNt8tOm+sCrfYLwxRBOKc/OMzQI3EAf97S9XgDzqTKr6mWbdXc3gdE5DN59 U0a1ahUQMH/Qsk1fXMksQIV3AfowmIKwU5Ahh4uJBRVucYqHJwKI0eNGsS/+VIWuEMyo eiOA== 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:content-transfer-encoding; bh=CGxG0/j7xC0/a4huNgmAxOnwb1bGe2VtlWCfROb5YG8=; b=hd2lA/uR9Brv5M1K3DdJPeo8bo48/rG1fbhl/7czco7joHp0MvekNgng49fasGPUS3 RHJFC2cdMNGwOaLtE5rJuoaM4MTdGylW2hpZoJHtQj/WZ0NcYE7NzBu0dcgutzW4nsnr 99mWyATpbAirGY3swKXh0bOqjMGv6neyYlgxKTS2ekx3LlKycKBnTS4EQb9oHfPO0syl Atb16SAeWOz2tSL3wbgdraaAcYPwlThMlilfmXYC4OoBZ2eEQypeNMpqvL5H644vysUW 9KWzpsODTbnXzy51msSmVugwzS+vqUbEM0BJw86XqHnaxmc8dVRA/DT+fkWbtQ3o2ORF iCrQ== X-Gm-Message-State: AKwxytcQ42Hd0Qy3RWzIz3NhfFhwrOMp79t8zjZ6Qoce0FyXCJ6X9TrL 7n5b7JdN9LUCJ2Eptu8zAU73JQGtshtygJbN7iAFjA== X-Google-Smtp-Source: ACJfBotHw66my7fVXSYlKgAIkDiycbC3fuENmqpqFNqidbHPo7iikrQEJb1FUUV/1UaT/iIqa+csNNIKA6Hl0sq2tSM= X-Received: by 10.157.91.51 with SMTP id x48mr4162193oth.206.1515262515840; Sat, 06 Jan 2018 10:15:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.8.86 with HTTP; Sat, 6 Jan 2018 10:15:15 -0800 (PST) In-Reply-To: <49CCE1C9-1DD1-4E71-A96F-3924A2571BDB@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> <49CCE1C9-1DD1-4E71-A96F-3924A2571BDB@postgresql.org> From: Simon Riggs Date: Sat, 6 Jan 2018 18:15:15 +0000 Message-ID: Subject: Re: Is this still accurate? To: "Jonathan S. Katz" Cc: Magnus Hagander , Steve Atkins , "pgsql-docs@postgresql.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 6 January 2018 at 16:35, Jonathan S. Katz wrote: > Hi, > > On Jan 6, 2018, at 9:45 AM, Magnus Hagander wrote: > > > > 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 t= hat >> 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 "larg= e" >> databases operationally, rather than just having large theoretical limit= s. >> >> Updating it would be great, or wrapping a little more verbiage around th= e >> 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/cluster= s >> can run without fixing people on a number. People can draw their own >> conclusions from the hard limits further down the page. >> > +1. I don't think that's as useful, so -1 for removing the stated limit. People always ask "how big can it go?" and having a specific number there is important. We have publicly documented cases above 50TB, so I think we should say that. Clusters in Petabyte range? We need to be able to substantiate that with publicly documented cases. They also need to be pure PostgreSQL, not "with added tech", no? Also, I can't see that the 1.6 TB per row is accurate, because that would mean 1600 toast pointers at 20 bytes each =3D 32000 bytes, which is above what we can normally support with 8kB blocksize as we normally shipped. Lastly, the "per table limit" should really say "32 TB per table, 128 PB for a partitioned table (4000 partitions)" --=20 Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services