Re: Dirty reads on index scan,

2023-09-22 Thread Koen De Groote
Alright. So, if I want to speed up the query, apart from trying to vacuum it beforehand, I suspect I've hit the limit of what this query can do? Because, the table is just going to keep growing. And it's a usually a query that runs one time per day, so it's a cold run each time. Is this just goi

Re: Dirty reads on index scan,

2023-09-22 Thread Laurenz Albe
On Fri, 2023-09-22 at 10:35 +0200, Koen De Groote wrote: > On Thu, Sep 21, 2023 at 9:30 PM Laurenz Albe wrote: > > On Thu, 2023-09-21 at 17:05 +0200, Koen De Groote wrote: > > > I'm doing the following query: > > > select * from my_table where hasbeenchecked = true and hasbeenverified = > > > tru

Re: Dirty reads on index scan,

2023-09-22 Thread Frits Hoogland
The actual thing that might be good to see is the query plan (explain). It is commonly regarded an issue to select ‘*’, in many cases only a subset of the rows are needed, but I don’t know your exact case. If a limited number of columns are actually needed from the table, it might help to create

Re: Dirty reads on index scan,

2023-09-22 Thread Koen De Groote
The "select * " is a replacement for the actual fields, which are all queried. I simply want to avoid pasting the entire query. The names that are there, too, are edited. >From what I'm reading, my best chance is to limit the amount of variables I need and change to index, plus tune for more frequ