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 1t0eZk-00CWZ0-Mf for pgsql-general@arkaria.postgresql.org; Tue, 15 Oct 2024 10:14:48 +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 1t0eZi-005VK0-Qq for pgsql-general@arkaria.postgresql.org; Tue, 15 Oct 2024 10:14:47 +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 1t0eZi-005VIm-G3 for pgsql-general@lists.postgresql.org; Tue, 15 Oct 2024 10:14:46 +0000 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t0eZg-001ADm-3z for pgsql-general@postgresql.org; Tue, 15 Oct 2024 10:14:46 +0000 Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a99b1f43aceso747195866b.0 for ; Tue, 15 Oct 2024 03:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728987283; x=1729592083; darn=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=ZW9jL7fLM2x+zZxZq+jmlHKgx3oNFHMbtT+BEy5O8rA=; b=aRR3yXYTTBSoPx5ls6ajaUXMH6AFV7SM8+TKAW2UYqL/CgtJKsv16QmJZYjx5yIe7a rYUdOrnWhTL5yorgUJNsqEf2eQhzTGAtPdt2tGIoBKI4EuLIwb8dWtoKL5OYPH+CnZJp ILsknQ74LTUTrVQKc9VpJSMCJCx96/orKhKthLPuL99/8AEnsIFJveEGcD8iZbPXaLq2 Qa47n/mC67WbWXC/exf3/0pxdZ57Tmad/1eYQ14IQg8RpMKsOuwCNVIZRL0kZZoS5b5z grporhJwQcBTH1FLLYD9+wYf1Ew0gyvhAVKXYD92k4Q67uqgHAYzkKtSiWKUhpaNdRXY qXIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728987283; x=1729592083; 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=ZW9jL7fLM2x+zZxZq+jmlHKgx3oNFHMbtT+BEy5O8rA=; b=PVRBnAbX3iuISJR69TnDP+ze0o3n0/QFBRrS5sgVjarZVPScQwv0v2yuKWfIGqgSBu CeqHYvvgYEPDVT0nZ4O8pn13DPAv0TIvyA75O3S0pNpuFgt06acND9HMfB/xg21qJ2XM 0+JXkCGzah31188slBtfn0f8NucJPwgwnfCgcCAls4ypqjGOBTzGu7W00KwvzzwnMeyH 7RbFVj8qChChPeT8xBHvz5eIDt6ssb8BESXXDyv901aUpQzj0TwbbxchVC7O0U0aDfF1 Fziipt1oJUGk4Ox0ImogqDN89Q0TaNC/rrUiPjV4kzMNKnqMb4GeJxdkEpaTITFPh6oy vZUA== X-Gm-Message-State: AOJu0Yz3rVcHw7X0sW7K+w9CxTrHeEW/ZZBrx1qiIPIhz7Mb/CfOAanG O4JKKKohPvuExuhAsfAW3mVvy9pRuaHxfdbFpdlHCXgWLXwHZVJtg8dI+w7rL7rLT3ar5Ur5hAC Kg3X5aqO8UG/dmlmHNunQ6VcktTc= X-Google-Smtp-Source: AGHT+IHPQWN6hmqLGnn+XNKvEwxHytKOrd12N/4evmYnFGGL4BEZouSIk5KzWAYNx3nIjfJvudgUxN2VKTkQcLJI9YI= X-Received: by 2002:a17:907:96a0:b0:a99:f298:c235 with SMTP id a640c23a62f3a-a99f298f43amr762442666b.7.1728987282616; Tue, 15 Oct 2024 03:14:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Durgamahesh Manne Date: Tue, 15 Oct 2024 15:44:26 +0530 Message-ID: Subject: Re: Inefficient use of index scan on 2nd column of composite index during concurrent activity To: David Rowley Cc: PostgreSQL mailing lists , Greg Sabino Mullane Content-Type: multipart/alternative; boundary="000000000000cd38610624813815" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000cd38610624813815 Content-Type: text/plain; charset="UTF-8" On Tue, 15 Oct, 2024, 15:15 David Rowley, wrote: > On Sat, 12 Oct 2024 at 02:28, Durgamahesh Manne > wrote: > > Second column of composite index not in use effectively with index scan > when using second column at where clause > > > > I have composite index on (placedon,id) of test > > When quering select * from test where id = '4234'; > > Value of id changes and during concurrent activity and cpu utilization > increased toomuch that i have observed which means query plan changed why > > > > I could see index scan with explain for it > > > > Is there any way to keep index scan for it during even on concurrency > rather than seperate index on second column of composite index ? > > It sounds like you might be asking about something we call "index skip > scans". Currently, PostgreSQL does not support these, however there is > work being done to add support and that might arrive in PG18. > > There is some information about a possible workaround in [1] which may > be of use to you. > > David > > [1] https://wiki.postgresql.org/wiki/Loose_indexscan Hi David Thanks you for valuable info Regards, Durga Mahesh > > --000000000000cd38610624813815 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, 15 Oct, 2024, 15:15 David Rowley, <dgrowleyml@gmail.com> wrote:
On Sat, 12 Oct 2024 at 02:28, Durgamahesh= Manne
<maheshpostgres9@gmail.com> wrote:
> Second column of composite index not in use effectively with index sca= n=C2=A0 when using second column at where clause
>
> I have composite index on (placedon,id) of test
> When quering=C2=A0 select * from test where id =3D '4234';
> Value of id changes and during concurrent activity and cpu utilization= increased toomuch=C2=A0 that i have observed which means query plan change= d why
>
> I could see index scan with explain for it
>
> Is there any way to keep index scan for it during even on concurrency = rather than seperate index on second column of composite index ?

It sounds like you might be asking about something we call "index skip=
scans". Currently, PostgreSQL does not support these, however there is=
work being done to add support and that might arrive in PG18.

There is some information about a possible workaround in [1] which may
be of use to you.

David

[1] https://wiki.postgresql.org/wiki/Loos= e_indexscan

Hi David

Than= ks you for valuable info=C2=A0

Regards,
Durga Mahesh=C2=A0

--000000000000cd38610624813815--