| From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
|---|---|
| To: | Frits Jalvingh <jal(at)etc(dot)to> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Postgres using nested loops despite setting enable_nestloop to false |
| Date: | 2020-11-17 14:20:24 |
| Message-ID: | 20201117142024.GA24784@telsasoft.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, Nov 17, 2020 at 02:47:55PM +0100, Frits Jalvingh wrote:
> But lately while migrating to Postgres 13 (from 9.6) we found that Postgres
> does not (always) obey the enable_nestloop = false setting anymore: some
>
> The execution plan on Postgres 13.1:
Could you send the plans under pg13 and pg9.6 as attachments ?
What is the setting of work_mem ?
I see the cost is dominated by 2*disable_cost, but I wonder whether the I/O
cost of hash joins now exceeds that. Maybe hash_mem_multiplier helps you?
GroupAggregate (cost=20008853763.07..20008853776.02 rows=370 width=68)
Group Key: (COALESCE(adres_pe.id_s, '-1'::integer)),
--
Justin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Frits Jalvingh | 2020-11-17 15:58:45 | Re: Postgres using nested loops despite setting enable_nestloop to false |
| Previous Message | Nunzia Vairo | 2020-11-17 13:54:03 | Install clustered postgres |