Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tBBac-002LhB-9T for pgsql-general@arkaria.postgresql.org; Wed, 13 Nov 2024 11:31:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tBBaZ-00Dbyp-49 for pgsql-general@arkaria.postgresql.org; Wed, 13 Nov 2024 11:31:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tBBaY-00Dbyh-MW for pgsql-general@lists.postgresql.org; Wed, 13 Nov 2024 11:31:11 +0000 Received: from mail-ed1-x544.google.com ([2a00:1450:4864:20::544]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tBBaU-001i9s-Aj for pgsql-general@lists.postgresql.org; Wed, 13 Nov 2024 11:31:10 +0000 Received: by mail-ed1-x544.google.com with SMTP id 4fb4d7f45d1cf-5cb6ca2a776so10221020a12.0 for ; Wed, 13 Nov 2024 03:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731497466; x=1732102266; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DXyV/eOJQ1Gg5TVOTgyWYcO9o4rmlN6RFHyqrdN6OFg=; b=bUh20XZVnJ3KnbLp/fgHrWRDGE2W7EDlf0eFW6x7cQXXE7+9rKu1LPaoBGViQvo8E1 y0m/EXsvIr3UuPnDEVsSqzcErDeGB0vL6und6/lSu5FSjcThVFQYrpOa08zh2oFJ36rn FVaE7NA4AaJTUdSesrR0D14f3j0YOxZG098wMhimIg7vtM17tOrmRkJFT7iPow1WQlV6 58OArgWxG1Mz2CUpMHzt8w9U9BGWhiGW8ev+O3aOAl1DqGgqL/+TNBqJfkltT++8/pwJ MwA3gFQXZ/rucr2fy67Q1wne7XqQWcXmGQ809Ho/z+baMMV98LkASr01lwORxWxQTgHE 8PKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731497466; x=1732102266; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DXyV/eOJQ1Gg5TVOTgyWYcO9o4rmlN6RFHyqrdN6OFg=; b=rD8+tJveJ0059RjFecq52ln394/RnOL/3sz9+mE8tZQmnzgT2m6Z3EnHYL42eIUTo5 +MnMtbQCjmmnSUxrnEg07ez0BTkF3XvqSYK++gGYod5SNIJ+0oWS/O6iKYKEztTnd8rh Y724dvsViyR4DGIvCLDO60AaXJLE0nkezvBPi0Q/kvnYpxwjZ4J7HyXwM2KJWswiFwuA wmvy6CAwukg9evG46SsA1WdNMVlJUEfuxjScvhIglQn94BD1WP0Rrv/h+Grcmzx31NCd JC4NHjd1ni9ytFJPpZR/qz6ccQRM6j4TiWAO24+IXUfLUBiyzDx2M6GdPSSk7Y8xcAd3 dLvg== X-Gm-Message-State: AOJu0Yz2alaKEG6otBLpI4+ZE9jWCb8uYHr0xZrtNhkylIOEos3C3I6w PSXDfkBD8f85xUpyTAfhFTGrfNbfi6wK+hx/kXBX6yeFdTZAhg8lk2Boq6VoxII76f/Uiyb9Tu7 NNgCFB/NKvKcFSvSTytMqHXhtTBwxxiL6 X-Google-Smtp-Source: AGHT+IHTrWyyqmjYdicDdtsDPMStsddaFpAt54ozcIKC0T5TYT9T9PtVFCiRkwF1FJdhtP5o/u8JoNcx9IAFob1btLg= X-Received: by 2002:a05:6402:1d49:b0:5cf:457:343a with SMTP id 4fb4d7f45d1cf-5cf4f362136mr5350980a12.16.1731497465433; Wed, 13 Nov 2024 03:31:05 -0800 (PST) MIME-Version: 1.0 References: <202411131029.qchduffwgzhm@alvherre.pgsql> <3a93d9b1-e2a1-4d33-b9fc-702b8d43cdba@cloud.gatewaynet.com> In-Reply-To: <3a93d9b1-e2a1-4d33-b9fc-702b8d43cdba@cloud.gatewaynet.com> From: Vijaykumar Jain Date: Wed, 13 Nov 2024 17:00:26 +0530 Message-ID: Subject: Re: Fwd: A million users To: Achilleas Mantzios - cloud Cc: pgsql-general Content-Type: multipart/alternative; boundary="0000000000005b58dc0626c9ab4e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000005b58dc0626c9ab4e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 13, 2024, 4:42=E2=80=AFPM Achilleas Mantzios - cloud < a.mantzios@cloud.gatewaynet.com> wrote: > > Exactly! In the later versions, security gets more and more refined and > strengthened. So ppl should think about moving away from "public" , and > start implementing finer grained schemes of security, as you suggest. + > \dp shows prettier than having 1000+ users listed. > I wanted to just communicate the limits. a lot of postgresql architecture can leverage the resources and scale, but not all. i had 100s of 1000s of tables on my setup where i worked last. if i did \dt it would freeze all the time. i had to exit the pdwl session, check the source code of how the partition was named and then look for what I wanted. if things are pretty with psql or not should not be a criteria for how many objects you want to have. i would expect clear exceptions so one knows what the real problem is. the error I got did not in anyway communicate the role limits for col size limits. --0000000000005b58dc0626c9ab4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 13, 2024, 4:42=E2=80=AFPM Achilleas Mantzi= os - cloud <a.mantzio= s@cloud.gatewaynet.com> wrote:

Exactly! In the later versions, security gets more and more refined and strengthened. So ppl should think about moving away from "public"= , and
start implementing finer grained schemes of security, as you suggest. + \dp shows prettier than having 1000+ users listed.

I wanted to just communic= ate the limits.
a lot of postgresql architecture can= leverage the resources and scale, but not all.
i ha= d 100s of 1000s of tables on my setup where i worked last.
if i did \dt it would freeze all the time. i had to exit the pdwl se= ssion, check the source code of how the partition was named and then look f= or what I wanted.
if things are pretty with psql or = not should not be a criteria for how many objects you want to have.

i would expect clear exceptions= =C2=A0 so one knows what the real problem is.
the er= ror I got did not in anyway communicate the role limits for col size limits= .


--0000000000005b58dc0626c9ab4e--