Search Postgresql Archives

Re: Regarding query optimisation (select for update)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux