From: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
---|---|
To: | Felipe López Montes <xocas89(at)gmail(dot)com> |
Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: Simple query with Planner underestimating rows. |
Date: | 2025-01-29 02:12:03 |
Message-ID: | CAKAnmmKQcrF_psSgVy++hUfv02R0h8hgUo7fpnxmO6UFSvEYrQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Jan 28, 2025 at 5:30 PM Felipe López Montes <xocas89(at)gmail(dot)com>
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
> strategy too. Instead now the planner goes for a merge join ( if you still
> prefer me to send you the nestloop plan, I can do):
>
Yes, please, send the exact plan you are having problems with. Also, what
exactly is the performance issue? It seems your *second best plan* is
running in 36 milliseconds?
Cheers,
Greg
P.S. In the future, you can use this to quickly grab relevant settings:
select name, current_setting(name) from pg_settings where source <>
'default';
From | Date | Subject | |
---|---|---|---|
Next Message | Andrei Lepikhov | 2025-01-29 03:05:50 | Re: Simple query with Planner underestimating rows. |
Previous Message | Felipe López Montes | 2025-01-28 19:29:18 | Simple query with Planner underestimating rows. |