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 1tBAz8-002IMX-W2 for pgsql-general@arkaria.postgresql.org; Wed, 13 Nov 2024 10:52:30 +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 1tBAz6-00DICz-Bp for pgsql-general@arkaria.postgresql.org; Wed, 13 Nov 2024 10:52:28 +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 1tBAz6-00DICr-1e for pgsql-general@lists.postgresql.org; Wed, 13 Nov 2024 10:52:28 +0000 Received: from mail-ot1-x32d.google.com ([2607:f8b0:4864:20::32d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tBAyy-001hsu-U5 for pgsql-general@postgresql.org; Wed, 13 Nov 2024 10:52:28 +0000 Received: by mail-ot1-x32d.google.com with SMTP id 46e09a7af769-7181b86a749so2964179a34.3 for ; Wed, 13 Nov 2024 02:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731495140; x=1732099940; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=shdEiVr5smsemOFWQ6E0FTXUE3MLRC7TGLrVx2S/isE=; b=GGIm77axe0Vf5qqJJT2AO2K/lkIfd5Pw1SBy8XMeLNyf6VPnA7Cy2lvmOI03bcPgQs ASbt+0XabazxqVpBP/UsYOk7TESF0og71IJpidkr4zMs2xRUK/vWjAYp1VpnFPGIAaaj NQ80PGD3OgrK7dfKXJxNLevlc+tswV+EelQYAfPUgSgkuw24HARsCntDNaAndeDbXDWd SJOxVKi1fi7RX6FgWRr25zvDvUV7RPePSjnPSBZQWgXcrx1CniEe9ZtaVuXaiGakVFAv ZHTTL5Iv9W/UkkOsfmD2G33A8z5h8s8/i7ERCkMYtPy6FuUCDcdA0z+Zea6zzf46cmwT Vbjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731495140; x=1732099940; h=content-transfer-encoding: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=shdEiVr5smsemOFWQ6E0FTXUE3MLRC7TGLrVx2S/isE=; b=GSQ4oUfSgMXUx7bm5yTcSbRQ3ZkKOV3Q4Q7+biUeFsWiCd6DiFTBLf0SE/MuJ1VkbB g6KCIsRbM2X/Htv9LypfyUmdQOYtDfzA0qJvSG/R9B78jtM6kZKVyWLe2Q4FTeRQol7n 1HyfduTzJG0ONIZf7YOJDstz9ord/Zf8sJOcAK8cEPoCb9wo0vOq3Sz1D/FU+IUr/dbO JZ0KYcqaVK99OHjWJrNUUdRk+S90NyfNuy/2+ZZLE12lI4XfNZ7PJc1/1ipbnIzum8nx eaR8X6Ps1x5eUaU6J8RCU0ZGzseQSax4TJvSgIw3dMzjcW+sFxgF7FD9ZOhcRosIla9I voKQ== X-Forwarded-Encrypted: i=1; AJvYcCU4RBbOKqjJiYUJIbhrk96Jekcq2tzyDC7FYuVhympEKAmZWaAeWreiga4v2WPTl1K2Zl5iWVYMPla7TzmC@postgresql.org X-Gm-Message-State: AOJu0Yzt11G4aozWwDDp9JaaBk4aM/2+tmhf1MnSUUPS9eXdEiDbC0Pz hh+PqSGfivAKGKjFajOWhbSGmR99hh7/pKx0ShsWBdHeYzb/eGOsvLq050HBG+Xpph7Bo84OUUZ ulsiypomNT73i+ZDblqoNLgcDcdkcnQ== X-Google-Smtp-Source: AGHT+IFVsxjeTWzK24BoI3qkqneiB+PVFJ2c8kCVIZrioL3AxOu6b2spgCNpS6aXGyQa9aiQPcSQ3Q/zikiPNV/BPpQ= X-Received: by 2002:a05:6870:5e53:b0:25d:ff1b:3793 with SMTP id 586e51a60fabf-295603d5892mr16309689fac.35.1731495140059; Wed, 13 Nov 2024 02:52:20 -0800 (PST) MIME-Version: 1.0 References: <202411131029.qchduffwgzhm@alvherre.pgsql> In-Reply-To: <202411131029.qchduffwgzhm@alvherre.pgsql> From: Dominique Devienne Date: Wed, 13 Nov 2024 11:52:08 +0100 Message-ID: Subject: Re: Fwd: A million users To: Alvaro Herrera Cc: Vijaykumar Jain , pgsql-general , "kaare@jasonic.dk" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Nov 13, 2024 at 11:29=E2=80=AFAM Alvaro Herrera wrote: > On 2024-Nov-13, Vijaykumar Jain wrote: > > I tried to grant select permissions to 5000 different roles on one tabl= e, > > It failed with row size too big already at 2443. > > But you can grant select to one "reader" role, and grant that one role > to however many other roles you want. This way you can have an > arbitrary number of roles with indirect access to the table. In > real-world usage, this is more convenient that granting access to > individual roles on individual tables; likely, you'll grant access to > sets of tables/views/functions/etc rather than exactly one, and you can > manage that more easily if you have one intermediate role to modify than > if you have to mess with 5000 individual roles. Hi. Sure, that's a good point, and a best practice IMHO. But I already do that, and the original question remain, i.e. how does PostgreSQL with thousands or millions of roles? In my use case, 1000 LOGIN users, and 10'000 schema related ROLEs, is possible, with can translate to millions of GRANTs. It matters to me especially, since I'm using pg_has_role() in RLS predicate= s, in addition to using ROLEs for access to schemas as usual (see above). I'm not in a point to test that myself at this time, but if anyone looked i= nto how PostgreSQL scales with many roles (O(N)? O(logN)? O(NlogN)?), I'd be interested in pointers to that research or those benchmarks. Thanks, --DD