You might want to examine the SKIP LOCKED feature as well, if you are using
this query to have multiple workers grab chunks of the table to work on
concurrently.
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
Laurenz Albe writes:
> Text is easier to read than images...
Indeed.
> Anyway, this statement was done in under a millisecond.
> I wouldn't call that slow...
It looks to me like this EXPLAIN ANALYZE was done against a totally
empty table, so probably in a freshly-set-up dev environment. That
i
On Tue, 2025-07-15 at 18:26 +0530, Durgamahesh Manne wrote:
> On Tue, Jul 15, 2025 at 6:14 PM Laurenz Albe 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, c
Can you try like: ORDER BY betid desc
---Original---
From: "Durgamahesh Manne"
0D59E1CB@A7AE4F48.30527668.png
Description: Binary data
On Tue, Jul 15, 2025 at 6:14 PM Laurenz Albe
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 = '
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
Hi Team,
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;
Q
