On 1/29/25 02:29, Felipe López Montes wrote:
Hi all,
I am using PostgreSQL 17.2 on x86_64-pc-linux-gnu, compiled by gcc (GCC)
12.4.0, 64-bit.
I have been facing this issue past weeks and I don't know what else to
try, I have a very simple query where the planner is underestimating the
numbe
On Tue, Jan 28, 2025 at 5:30 PM Felipe López Montes
wrote:
> For the sake of clarity and simplicity, I have disabled the nestloop join
> in the session because it involved a gather clause and parallel workers and
> was still underestimating rows, so the same problem happens with nestloop
> strate
On Mon, 2025-01-27 at 12:29 +, Praveen Kumar Mandula wrote:
> Attaching linux and windows logs, are they useful in identifying why its
> taking time more in windows ?
No.
Yours,
Laurenz Albe
Not an official postgres reply, I’m just some guy…
You added to the OR to ::text.
It would have to do a SEQ scan to perform a search ::text on the column, as it
doesn’t know the column’s ::text value(s).
I think if you make another index on the column::text, the SEQ scan would be an
index scan
Hello,
Any idea what could cause postgresql (16.0) to fall back to a SeqScan
when ORing a falsy one-time filter to a selection which would
otherwise use an index scan?
1.) Without the false one-time condition, the query uses the existing
index on owner to perform the lookup:
select * from mytable
