| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Quan Zongliang <quanzongliang(at)yeah(dot)net> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Why enable_hashjoin Completely disables HashJoin |
| Date: | 2023-04-04 13:50:05 |
| Message-ID: | CA+TgmobFF9HwC_vVzTsrrC5nUs4U5ugE7w3=UXgKfNbAJAqaRg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Apr 4, 2023 at 3:38 AM Quan Zongliang <quanzongliang(at)yeah(dot)net> wrote:
> Because someone noticed that when he set enable_hashjoin,
> enable_mergejoin and enable_nestloop to off. The statement seemed to get
> stuck (actually because it chose the NestedLoop path, which took a long
> long time to run).
> If enable_hashjoin and enable_nestloop disable generating these two
> paths. Then enable_nestloop should do the same thing, but it doesn't.
This all seems like expected behavior. If you disable an entire plan
type, you should expect to get some bad plans. And if you disable all
the plan types, you should still expect to get some plan, but maybe an
extremely bad one.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2023-04-04 14:20:00 | Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID |
| Previous Message | Amit Kapila | 2023-04-04 13:43:26 | Re: Minimal logical decoding on standbys |