| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: allowing extensions to control planner behavior |
| Date: | 2024-08-28 20:12:47 |
| Message-ID: | CA+TgmoY9NrPp6U+6Px7_Mwmbj4Bph203ON2RGyYYRdcn8JkHJg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Aug 28, 2024 at 3:23 PM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> On Tue, 2024-08-27 at 15:11 -0400, Robert Haas wrote:
> > - control over scan methods
> > - control over index selection
> > - control over join methods
> > - control over join order
>
> I suggest we split join order into "commutative" and "associative".
>
> The former is both useful and seems relatively easy -- A JOIN B or B
> JOIN A (though there's some nuance about when you try to make that
> decision).
>
> The latter requires controlling an explosion of possibilities, and
> would be an entirely different kind of hook.
My proposal in http://postgr.es/m/CA+TgmoZQyVxnRU--4g2bJonJ8RyJqNi2CHpy-=nwwBTNpAj71A@mail.gmail.com
seems like it can cover both cases.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2024-08-28 20:27:38 | query ID goes missing with extended query protocol |
| Previous Message | Jeff Davis | 2024-08-28 19:23:52 | Re: allowing extensions to control planner behavior |