| From: | Michael Lewis <mlewis(at)entrata(dot)com> |
|---|---|
| To: | Alexander Stoddard <alexander(dot)stoddard(at)gmail(dot)com> |
| Cc: | "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Thomas Kellerer <shammat(at)gmx(dot)net> |
| Subject: | Re: Accounting for between table correlation |
| Date: | 2021-01-19 20:47:18 |
| Message-ID: | CAHOFxGrwYK41=e0BESL0ZNRvebZCe8ZKm+ZNkie5zz+64FgOxQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Fri, Jan 15, 2021 at 3:27 PM Alexander Stoddard <
alexander(dot)stoddard(at)gmail(dot)com> wrote:
> The queries are complex, multiple joins to 10 plus tables, although most
> are to tiny enum type lookup tables. I believe it is the join between the
> two large tables that I have described that causes the issue, and that
> seems to be reflected in the different strategies in the plans. For my own
> learning and to clarify the problem I probably will have to try and
> reproduce the behavior in a test case.
> ...
> I am doing nothing to specify the optimizer. Do I have configurable
> options in that regard? I was unaware of them.
>
Read up on join_collapse_limit and geqo.
https://www.postgresql.org/docs/current/runtime-config-query.html
Note that you can set these values within your session to check and even
just run explain [query] to check if the plan that would be used varies.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Stoddard | 2021-01-19 22:03:53 | Re: Accounting for between table correlation |
| Previous Message | Alvaro Herrera | 2021-01-19 20:37:51 | Re: Error messages on duplicate schema names |