Re: Regarding query optimisation (select for update)
От | Laurenz Albe |
---|---|
Тема | Re: Regarding query optimisation (select for update) |
Дата | |
Msg-id | c116cd0011bb36a55f58274daecf4464a23911e7.camel@cybertec.at обсуждение исходный текст |
Ответ на | Regarding query optimisation (select for update) (Durgamahesh Manne <maheshpostgres9@gmail.com>) |
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: