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 1szElJ-004yoT-7b for pgsql-general@arkaria.postgresql.org; Fri, 11 Oct 2024 12:28:53 +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 1szElH-003Afh-Eh for pgsql-general@arkaria.postgresql.org; Fri, 11 Oct 2024 12:28:51 +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.94.2) (envelope-from ) id 1szElH-003AfY-3D for pgsql-general@lists.postgresql.org; Fri, 11 Oct 2024 12:28:51 +0000 Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1szElE-000MdN-V0 for pgsql-general@lists.postgresql.org; Fri, 11 Oct 2024 12:28:50 +0000 Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5c9150f9ed4so2496007a12.0 for ; Fri, 11 Oct 2024 05:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728649727; x=1729254527; 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=r/R0W/vZtlkwgENcnHPN5UX+EjLZ9WUDKlYmCKAUw8E=; b=aibVqf8cs8ICxvwozkbwjDtT8XmfV34AhHy3kGCojKuCngI8FIYnWx5gWJ3I+BVsLI +UWUCTt5Lb1xmV+PETITtKins4u7teQRsiZeV4E5Lc/rQTQa6njfrSW0s8TdrmIF9ku4 h+f1/HPQTLICa/Om7PKHeXl4I7OZqsltYDlyi8Ap6PMuaMvWzKe1zeQ13E9O+sNeag+K G/NRusYmRMT3+Lx+qdPXivOVNeqnmYVD0+PPTOnk4tXQZzL0WHVv3va40KU6+i3Y+sWW OactKlJ/jyjxxLOqNU/7oJ7cTuViA7Y+swEMdmqlWc1IE3qlb/kT7KC/Qp3BgFRErURh pFJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728649727; x=1729254527; 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=r/R0W/vZtlkwgENcnHPN5UX+EjLZ9WUDKlYmCKAUw8E=; b=fdsTepKGVxf95h3mQI6Ie/Zw6YnlF+9k++v/5V06mczXkEDd7XaFB7NrR8FpmNYg7a whto1j8aGVpOUdBR4/A1rwkmeiwfEUXpX61BQFY1r68zzXbS6kJGz2B+Siym888lBgU4 UnffvkIyMJWLNvxqNaAA8WBIyg22O8syMY/gkfuCGc5VWjJG1k0y1dp8qdxG87sFC+rl 50RdvzplWgJjBtCqIESapIxjdZ/FohQei2TSzHpkOKlxozXoIdtI/TKi7Q7l61VDNuhG vraklq77NgN3qw/iDWSevO3r7RxROI9Q3aMqs1s8uTTZ5Z05SRtKacsrvqd1lGvmnRuq mWkQ== X-Forwarded-Encrypted: i=1; AJvYcCUs/TyrEsdaRqotNzT9WsNPE9vXkA7DhZo09+BW6Xzs5okSbauqVMxq47WbtCH+PpEM7YYL7e93HT0aoP0y@lists.postgresql.org X-Gm-Message-State: AOJu0YxfWPUP8SDkVBfCusmvnmXS/DuLr5sj+cVks66sJD65zRepwXrb o89yYRwQZM2aegnBtie5VXAqO1QUrYL+owMt1k3LDM05NNatfm0SEDKL4jS9cWh1WhSqsB6Y0yZ b58QtFdEgMEzZWmO3J8Xbot3SsV8= X-Google-Smtp-Source: AGHT+IExU1PvULXHnOehud5YSdDBze4sLvBupgc1Wbvc1dj7WBnRNVCPoGbT9TuoZ1Kfj6vvuLVKBx+R5MwJf+cl9JE= X-Received: by 2002:a17:907:e60d:b0:a90:41a5:bb58 with SMTP id a640c23a62f3a-a99b94533e1mr199500266b.16.1728649727287; Fri, 11 Oct 2024 05:28:47 -0700 (PDT) MIME-Version: 1.0 References: <88e5c335-c70e-4973-9b71-6c12e251e5b7@ewie.name> In-Reply-To: From: Durgamahesh Manne Date: Fri, 11 Oct 2024 18:01:58 +0530 Message-ID: Subject: Re: Question on indexes To: Greg Sabino Mullane Cc: sud , Erik Wienhold , xof@thebuild.com, pgsql-general Content-Type: multipart/alternative; boundary="000000000000efaa68062432a050" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000efaa68062432a050 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 11, 2024 at 5:00=E2=80=AFPM Greg Sabino Mullane wrote: > if we have any column with large string/text values and we want it to be >> indexed then there is no choice but to go for a hash index. Please corre= ct >> me if I'm wrong. >> > > There are other strategies / solutions, but we would need to learn more > about your use case. > > Cheers, > Greg > > Hi Respected Team How do we enforce the secondary column of composite index to index scan on concurrent activity in postgres? 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 querying select * from test where id =3D '4234'; Value of id changes and during concurrent activity and cpu utilization increased too much that i have observed which means query plan changed why I could see index scan with explain for it on singal call or double calls Is there any way to keep an index scan for it during concurrency rather than a separate index on the second column of the composite index ? Regards, Durga Mahesh --000000000000efaa68062432a050 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Oct 11, 2024 at 5:00=E2=80=AF= PM Greg Sabino Mullane <htamfids@g= mail.com> wrote:
if w= e have any column with large string/text values and we want it to be indexe= d then there is no choice but to go for a hash index. Please correct me if = I'm wrong.

There are ot= her strategies / solutions, but we would need to learn more about your use = case.

Cheers,
Greg
=C2=A0

Hi Respected Team
<= br>
How do we enforce the secondary column of composite index to index= scan on concurrent activity in postgres?=C2=A0=C2=A0
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=C2= =A0
When querying=C2=A0 select * from test where id = =3D '4234';
Value of id changes and during c= oncurrent activity and cpu utilization increased too much=C2=A0 that i have= observed which means query plan changed why

I could see index scan with explain for it=C2=A0 on si= ngal call or double calls

Is there any way to keep an index scan for it during concurrency rather t= han a separate index on the second column of the composite index ?


Rega= rds,
Durga Mahesh=C2=A0=C2=A0
--000000000000efaa68062432a050--