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 1rwokv-004Mu1-Q3 for pgsql-general@arkaria.postgresql.org; Tue, 16 Apr 2024 19:46: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 1rwokt-005yWq-T5 for pgsql-general@arkaria.postgresql.org; Tue, 16 Apr 2024 19:46: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 1rwokt-005yWi-Hy for pgsql-general@lists.postgresql.org; Tue, 16 Apr 2024 19:46:11 +0000 Received: from mail-vk1-xa2a.google.com ([2607:f8b0:4864:20::a2a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rwokr-001K2J-6H for pgsql-general@lists.postgresql.org; Tue, 16 Apr 2024 19:46:10 +0000 Received: by mail-vk1-xa2a.google.com with SMTP id 71dfb90a1353d-4daa8e622f0so1785193e0c.1 for ; Tue, 16 Apr 2024 12:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713296767; x=1713901567; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=3tJDADVNSFLgRgOsqCmkjW/ubYovhSD06hoZ9zNL15o=; b=OGhg3LOVXGTCGR/niizlCvsrA/k/o9QzonwMzsF+FuY2Vhhu6E0b+xa8bSlqptuL9k 1oKdsKbR8tqlY8/a75MCyI+lmDAMHZhbHZ9gaODEmV8VTKdjs6et55JNq4tD9kZlz5X3 dpIfAd65oUnWYU6mWF+HMomP53jKVfpiBoFHdWSoWtvg8DmJoSf2cuOYEqYLaVhEBUZz /a/0r9Aq8l7eaCVJoijD7LkBYcxBr9QYO1dSv9VhxfsPsewx9xX78YE8KgcwOBPztl0S ufQ+HKTQmY+Jh+8uEWM8omDT1HnKJL31DWfo5ZakDj9n/cLLcbOAMuYwWkidolphbxG+ dyYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713296767; x=1713901567; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=3tJDADVNSFLgRgOsqCmkjW/ubYovhSD06hoZ9zNL15o=; b=qwgISrId0b8BH45OAZv9/oOaLRe+7IR/olJxvKnCK4bLRc3xXnG0SLSluNX5yBh+gt d8wlgJMw6HYQDl5uV3h1nxyj3U0olMuK5G3dPZPlKLWzgf4uJsqWDAuFDwMZLB6tbwhG saoEyYan7Qq4vTKGHhy3H9zW0iMgaHFZKCE1BLeWb69dNWEoLl9R5JmWIych1s6iYx6i OtSS5GNj5ddC4WVx/HzRY/t6pvY75Fm8fd1d6UiwALNauqUigL40/s9dwd2ia8E8/GDC lp9fBVRfu5eXw/kxLvJYWQNcDFIyxgvFU+ySOf0XjAJj6Qj4kCIVw+vSYJnjg3bnJgMM 2D/Q== X-Gm-Message-State: AOJu0YwVDkd8bCJc6gB3y7RNMzTVYm/XSolAxaV49m9rxwKrq2LAfZTi LlWk4aCyC6FkdmygmM7pUWYX3fN+X2kZMp7sYoSVdNQZDdXI2TZM/p+teOID87CgoVQ2ZI4aD3J ZilATPrWXl/lLOoj0fcGixQj8007uJPq9 X-Google-Smtp-Source: AGHT+IH8DgD8cFhvntRum1tp1a9axWnKBBTIX3iRg1bosCEl9FcbSkjruBRYxGuiwCpp9vwgA20gM4nVQk3wmnnIIQM= X-Received: by 2002:a05:6122:7d1:b0:4d3:3446:6bc9 with SMTP id l17-20020a05612207d100b004d334466bc9mr11232274vkr.14.1713296766462; Tue, 16 Apr 2024 12:46:06 -0700 (PDT) MIME-Version: 1.0 From: yudhi s Date: Wed, 17 Apr 2024 01:15:54 +0530 Message-ID: Subject: Controlling resource utilization To: pgsql-general Content-Type: multipart/alternative; boundary="00000000000028fde806163bfdad" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000028fde806163bfdad Content-Type: text/plain; charset="UTF-8" Hi , We want to have controls around the DB resource utilization by the adhoc user queries, so that it won't impact the application queries negatively. Its RDS postgresql database version 15.4. Saw one parameter as statement_timeout which restricts the queries to not run after a certain time duration and queries will be automatically killed/cancelled. However, I don't see any other options to set this at user level, rather it's getting set for all or at session level. So I want to know if there exists, anyway to control the database resource utilization specific to users? Regards Yudhi --00000000000028fde806163bfdad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi ,
We want to have controls around the DB resource u= tilization by the adhoc user queries, so that it won't impact the appli= cation queries negatively. Its RDS postgresql database version 15.4.
Saw one parameter as statement_timeout which restricts the que= ries to not run after a certain time duration and queries=C2=A0will be auto= matically killed/cancelled. However, I don't see any other options to s= et this at user level, rather it's getting set for all or at session le= vel. So I want to know if there exists, anyway to control the database reso= urce utilization specific to users?

Regards
Yu= dhi

--00000000000028fde806163bfdad--