Re: Regarding query optimisation (select for update)

On Tue, Jul 15, 2025 at 6:14 PM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
wrote:

> On Tue, 2025-07-15 at 15:40 +0530, Durgamahesh Manne wrote:
> > We are facing issues with slow running query
> > SELECT betid, versionid, betdata, processed, messagetime, createdat,
> updatedat
> > FROM praermabetdata where processed = 'false'
> > ORDER BY betid, versionid LIMIT 200 OFFSET 0 FOR UPDATE;
> >
> > QUERY PLAN
> >
> --------------------------------------------------------------------------------------------------------------------------------
> > Limit (cost=0.28..1.89 rows=1 width=78)
> > -> LockRows (cost=0.28..1.89 rows=1 width=78)
> > -> Index Scan using
> idx_praermabetdata_processed_betid_versionid on praermabetdata
> (cost=0.28..1.88 rows=1 width=78)
> > Index Cond: (processed = false)
> >
> > image.png
> >
> > Do we have any alternative way to improve the performance?
> > Sometimes processed column use true as well as false
>
> Please provide EXPLAIN (ANALYZE, BUFFERS) output and use "log_lock_waits"
> to see if you are hanging behind locks for a longer time.
>
> Yours,
> Laurenz Albe
>
Hi Team

[image: image.png]

I can use log_lock_waits to check further information

Regards,
Durga Mahesh