public inbox for [email protected]
help / color / mirror / Atom feedFwd: Inefficient use of index scan on 2nd column of composite index during concurrent activity
2+ messages / 2 participants
[nested] [flat]
* Fwd: Inefficient use of index scan on 2nd column of composite index during concurrent activity
@ 2024-10-11 13:31 Durgamahesh Manne <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Durgamahesh Manne @ 2024-10-11 13:31 UTC (permalink / raw)
To: pgsql-general; Greg Sabino Mullane <[email protected]>
---------- Forwarded message ---------
From: Durgamahesh Manne <[email protected]>
Date: Mon, Oct 7, 2024 at 10:01 AM
Subject: Inefficient use of index scan on 2nd column of composite index
during concurrent activity
To: <[email protected]>
Hi team
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 ?
Hope everyone understand this
Regards,
Durga Mahesh
Hi Greg
you mentioned that below
(please start a new thread in the future rather than replying to an
existing one)
You cannot query on b and use an index on (a,b) as you observed. However,
you can have two indexes:
index1(a)
index2(b)
Postgres will be able to combine those when needed in the case where your
WHERE clause needs to filter by both columns. So then you no longer need
the two-column index.
Hi Greg ,
Here not using composite index on ordinary table.
Composite index that i use on partitioned table is mandatory for use to
replicate data to target using pglogical (sorry this is not mentioned
earlier)
composite key (placedon,id)
In concurrent mode if i use id at where clause then query plan for that id
column changes
How to mitigate it rather than use seperate index for id to continue
without change in query plan (index scan) during concurrent activity
I hope you understand this
Regards,
Durga Mahesh
Cheers,
Greg
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Inefficient use of index scan on 2nd column of composite index during concurrent activity
@ 2024-10-11 16:26 Greg Sabino Mullane <[email protected]>
parent: Durgamahesh Manne <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Greg Sabino Mullane @ 2024-10-11 16:26 UTC (permalink / raw)
To: Durgamahesh Manne <[email protected]>; +Cc: pgsql-general
On Fri, Oct 11, 2024 at 9:28 AM Durgamahesh Manne <[email protected]>
wrote:
> composite key (placedon,id)
> In concurrent mode if i use id at where clause then query plan for that id
> column changes
>
> How to mitigate it rather than use seperate index for id to continue
> without change in query plan (index scan) during concurrent activity
>
Why the focus on "concurrent mode"? Perhaps explain what you mean by that.
Speaking of explain, it might help if you show us the explain plans and how
they are not coming out how you want. Also the table definitions, but feel
free to not show columns unrelated to the problem.
Cheers,
Greg
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-10-11 16:26 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-10-11 13:31 Fwd: Inefficient use of index scan on 2nd column of composite index during concurrent activity Durgamahesh Manne <[email protected]>
2024-10-11 16:26 ` Greg Sabino Mullane <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox