Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eMybx-0003jp-6N for pgsql-performance@arkaria.postgresql.org; Thu, 07 Dec 2017 16:01:21 +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 1eMybw-0005pj-OO for pgsql-performance@arkaria.postgresql.org; Thu, 07 Dec 2017 16:01:20 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eMybw-0005pZ-EZ for pgsql-performance@lists.postgresql.org; Thu, 07 Dec 2017 16:01:20 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eMybu-0007Lt-5e for pgsql-performance@postgresql.org; Thu, 07 Dec 2017 16:01:19 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id vB7G1Dj4006685; Thu, 7 Dec 2017 11:01:13 -0500 From: Tom Lane To: =?UTF-8?Q?Ulf_Lohbr=C3=BCgge?= cc: Scott Marlowe , Andres Freund , "pgsql-performance@postgresql.org" Subject: Re: [PERFORM] Slow execution of SET ROLE, SET search_path and RESET ROLE In-reply-to: References: Comments: In-reply-to =?UTF-8?Q?Ulf_Lohbr=C3=BCgge?= message dated "Thu, 07 Dec 2017 13:54:15 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6683.1512662473.1@sss.pgh.pa.us> Date: Thu, 07 Dec 2017 11:01:13 -0500 Message-ID: <6684.1512662473@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk =?UTF-8?Q?Ulf_Lohbr=C3=BCgge?= writes: > I could reproduce part of the things I described earlier in this thread. A > guy named Andriy Senyshyn mailed me after reading this thread here (he > could somehow not join the mailing list) and observed a difference when > issuing "SET ROLE" as user postgres and as a non-superuser. This isn't particularly surprising in itself. When we know that the session user is a superuser, SET ROLE just succeeds immediately. Otherwise we have to determine whether the SET is allowed, ie, is the session user a member of the specified role. It looks like the first time such a question is asked within a session, we build and cache a list of all the roles the session user is a member of (directly or indirectly). That's what's taking the time here --- apparently in your test case, the "admin" role is a member of a whole lot of roles? regards, tom lane