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.96) (envelope-from ) id 1vrmS9-005fYs-0d for pgsql-general@arkaria.postgresql.org; Mon, 16 Feb 2026 00:27:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vrmS6-002rRS-2a for pgsql-general@arkaria.postgresql.org; Mon, 16 Feb 2026 00:27:02 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vrmS6-002rRK-15 for pgsql-general@lists.postgresql.org; Mon, 16 Feb 2026 00:27:02 +0000 Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vrmS3-00000000nyL-0bp6 for pgsql-general@lists.postgresql.org; Mon, 16 Feb 2026 00:27:01 +0000 Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-b8869cd7bb1so403145766b.1 for ; Sun, 15 Feb 2026 16:26:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771201617; cv=none; d=google.com; s=arc-20240605; b=iLgvDOeRwF4NiVhbSdSmjVyy4lLZFhhqpM08o7VucyJd1tyqY8pPKrE/NKxQeSX8CA Y6WcpvW7DEi6OTLJBVCDi7gT0Hnso8qjRMLo8qfCY85ikkGgtrQ8YOdsQ40Zid4vhNq6 8YFQh8ifJWx5Wrv5jfUry1rbSES6gO+ymnr1o98so2MJFBLWJl7xIgT9RO6OnACHXhvW E3/wSRYlYjMTN/HirlASnEMY+hhqsDFD9IoO8i4Y7pozJ555abk0lhwOmTZzs0F0qKA0 BvkY2nGrVuPEMRSkB+d49YxvqTFvZsBoGt+aTXvbAqJR85Z4GnZnpZJkBzChJDtijTNm 2iaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=LevQsAAob7y6IFZtm4J4ki7A+yFyS5zETz+7oMshHdM=; fh=4AmvT0UbUTU+6Z634cJ2hJKFZK5UOplxsrWc+8sAZCo=; b=Qvzn8l2meK1GnVxAF+fUknJGm07JMHqxdA/yNC5h3deYcv2lcWhCvEFdx8HJSaCr3k vdis1+d5sSfyAbC1R0LVOJHj/ekf6j+9DI7LItDYrOvBRftxavgoI2B7m2QrFDFttG+s 7RHgfxTwZouY3SwHTrurcK+EOlFbgs8uZ8gp4fNW7nxA63VxGrog1wf/iXPYBx4/tgMe 23F39FYjxEZGkSMKtDwKBq1YJd8U4PvyghHMM2jpwkWyx2XReqAxjXQKqbhcxu8EqNQA IiG8zfLF7/oPbpNSHo8IyYO4BsZvnUwZXCUDy8q1cINRVP48C+FD7GSfyhDUyD+Z33Ba DTUA==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771201617; x=1771806417; 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=LevQsAAob7y6IFZtm4J4ki7A+yFyS5zETz+7oMshHdM=; b=LMR7YfDchvqcpDjOK+Bv4yb9A2r0zpHp8O41qsHSah13wGc7wQm+E5pF9UtzL9zwY5 orjxuE7qNJgo7s8WhRu51+z7FzAbA/ZqI77vo0duPT9rP9GDKtVHmnTBIj+yKyWOw9M9 wHYlUASAOHH7P8Egvw8Hp+lkvwYVgpGACFK8XCcZE91CDRZi6e4RApb3KdaR5pW7isxz Ac3i/SNEnsuo05PFfZJ3jYG/+VUKkYt7quweerWpbSQSPlzPsfbBiHFoL9daKAAz/Jzn 0tGWsRkmhS0sc0zUp/d2wJWkju2yyqSwci0ln9/aqR6Uo/g6oGack+lFrUTFF9FCSj2g CxRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771201617; x=1771806417; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LevQsAAob7y6IFZtm4J4ki7A+yFyS5zETz+7oMshHdM=; b=gnZPou9hBoeUlo3PznAYE9wMFLkgd3w/p3feVAzhyyGu8abJutfoH2z9TAxcp8AvZO gdstCSFcYD2OutAAZ+cwQBBf4sM+5+BY2YsdE1SawWo67bnXiMaLGjJCyWq1px5nu14j IKtjWrt6gUdovcOT2FfvGr+Ra+lgUWnEL95BXwd+AweRtxDx3/3hEd7wb19Ysp2SKhDZ T3EVduwv6nMFTNcpuQ4+ur0haKBBYnkeBYEBts0A9XYiKV8uRGOJpwwODKx5yaXevmxV NCr/XcZPRfuBzbmeZIEHwsDr+oIRQ61nIuSpfzvHOa2hqI8LL1wHVfohrcMoSqWkt9q6 7lgw== X-Forwarded-Encrypted: i=1; AJvYcCUdhQAFsyT2WXspj2dFJ5mK219KtfHnryEWlpmRZGz3o9kGLyUPMIw3s6knQYC9xKZKqKiH/byKuAe3Gy5W@lists.postgresql.org X-Gm-Message-State: AOJu0YxDof31nnLV5LFWSrs98xFacN4Q2d4ZxxoBvoAgmrnAgOJEgZz9 XR2FkuPxl0bvkfgV1Z9W9CG3HgtN1bpjqW94VD2ycbk2f6yg/SfAGi8MTdU2KBNNWx+LKaw0wKE sCpOAJbtiqos4uKcIpuNZtqmR0d9QzbM= X-Gm-Gg: AZuq6aJX8BMzPWr6+Mi/MB8M4JQ+86xY38ugCmAFuHT83vX28hbAk+IJTWS6jSGNLA8 UyXbsfexcM6MtaQSTbWxNvLVswJswfy+Lbwcq/fe12bK6aaJ3A0UQQXLZvMeNaAvxmLZzkVJPS3 tqeqP07NQ6I76/3dMyusKYrNMvAtCZLuMQAh2g3N+85nhwKxAjeLjlw6qKigCmHrqGspAD8So9I bBhNFNUM5c9inGd2yFY4z5VzPsYyKuoPuwKP4iyi31mgPo5uO2q21rAvBobHPuLkJUwcwuMx6TZ V1KCqRQE X-Received: by 2002:a17:907:7285:b0:b8d:be69:78bf with SMTP id a640c23a62f3a-b8fc3a34e8amr313458366b.20.1771201616643; Sun, 15 Feb 2026 16:26:56 -0800 (PST) MIME-Version: 1.0 References: <826536fd65cb6b25e996ac449336ce9c2476174b.camel@cybertec.at> <903134.1752590744@sss.pgh.pa.us> In-Reply-To: From: Durgamahesh Manne Date: Mon, 16 Feb 2026 05:56:44 +0530 X-Gm-Features: AaiRm53o45xi8qEO9nyWOmEQwZOmc1LQlfEivCeKa5dN5zb_SEqdY6207baAM54 Message-ID: Subject: Re: Regarding query optimisation (select for update) To: Greg Sabino Mullane Cc: Tom Lane , Laurenz Albe , pgsql-general Content-Type: multipart/alternative; boundary="0000000000002f88f6064ae60346" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002f88f6064ae60346 Content-Type: text/plain; charset="UTF-8" On Tue, 15 Jul, 2025, 20:21 Greg Sabino Mullane, wrote: > You might want to examine the SKIP LOCKED feature as well, if you are > using this query to have multiple workers grab chunks of the table to work > on concurrently. > > Cheers, > Greg > > -- > Crunchy Data - https://www.crunchydata.com > Enterprise Postgres Software Products & Tech Support > Hi We are facing issues with session blocking > e3scoring=> \d+ competition_category Table > "e3scoring.competition_category" Column | Type | Collation | Nullable | > Default | Storage | Compression | Stats target | Description > --------------+-----------------------------+-----------+----------+---------+----------+-------------+--------------+------------- > id | character varying(36) | | not null | | extended | | | name | character > varying | | | | extended | | | short_name | character varying | | | | > extended | | | sport_id | character varying(36) | | | | extended | | | > competitions | jsonb | | | | extended | | | sort_factor | real | | | | > plain | | | brand_id | character varying(36) | | not null | | extended | | > | created_at | timestamp without time zone | | | now() | plain | | | > modified | timestamp without time zone | | | | plain | | | version | > integer | | not null | 0 | plain | | | Indexes: "competition_category_pk" > PRIMARY KEY, btree (id) "unique_name_brand_sport" UNIQUE CONSTRAINT, btree > (name, brand_id, sport_id) Foreign-key constraints: > "competition_category_fk" FOREIGN KEY (brand_id) REFERENCES brand(brandid) > Access method: heap Options: fillfactor=75 > select "version", competitions from competition_category cc where name = $1 and brand_id = $2 and sport_id = $3 FOR UPDATE Is there any best approach to optimize this with out sessions blocking most of the time while running mentioned query? Regards Durga Mahesh > --0000000000002f88f6064ae60346 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, 15 Jul, 2025, 20:21 Greg= Sabino Mullane, <htamfids@gmail.c= om> wrote:
=
You might want to examine the SKIP LOCKED feature as well,= if you are using this query to have multiple workers grab chunks of the ta= ble to work on concurrently.

Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support

Hi

= We are facing issues with session blocking=C2=A0
e3scoring=3D> \d+ competition_category Table "e3scoring.co= mpetition_category" Column | Type | Collation | Nullable | Default | S= torage | Compression | Stats target | Description --------------+----------= -------------------+-----------+----------+---------+----------+-----------= --+--------------+------------- id | character varying(36) | | not null | |= extended | | | name | character varying | | | | extended | | | short_name = | character varying | | | | extended | | | sport_id | character varying(36)= | | | | extended | | | competitions | jsonb | | | | extended | | | sort_fa= ctor | real | | | | plain | | | brand_id | character varying(36) | | not nu= ll | | extended | | | created_at | timestamp without time zone | | | now() = | plain | | | modified | timestamp without time zone | | | | plain | | | ve= rsion | integer | | not null | 0 | plain | | | Indexes: "competition_c= ategory_pk" PRIMARY KEY, btree (id) "unique_name_brand_sport"= ; UNIQUE CONSTRAINT, btree (name, brand_id, sport_id) Foreign-key constrain= ts: "competition_category_fk" FOREIGN KEY (brand_id) REFERENCES b= rand(brandid) Access method: heap Options: fillfactor=3D75

select "version", competitions from competition_category cc wh= ere name =3D $1 and brand_id =3D $2 and sport_id =3D $3 FOR UPDATE

Is there any best approach to op= timize this with out sessions blocking most of the time=C2=A0 while running= mentioned query?

Regard= s
Durga Mahesh
--0000000000002f88f6064ae60346--