From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Behrang Saeedzadeh <behrangsa(at)gmail(dot)com> |
Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: Get the planner used by a query? |
Date: | 2019-10-09 18:15:50 |
Message-ID: | CAKJS1f8zmVedgD+uXTCm-urZASNStkb4uHq0eYD86EfKHka_qA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, 9 Oct 2019 at 19:21, Behrang Saeedzadeh <behrangsa(at)gmail(dot)com> wrote:
>
> Is there a way to display the planner algorithm used by a query, either in EXPLAIN or in a different way?
There's not really any simple way to know. If the number of relations
in the join search meets or exceeds geqo_threshold then it'll use the
genetic query optimizer. However, knowing exactly how many relations
are in the join search is not often simple since certain types of
subqueries can be pulled up into the main query and that can increase
the number of relations in the search.
If you don't mind writing C code, then you could write an extension
that hooks into join_search_hook and somehow outputs this information
to you before going on to call the geqo if the "enable_geqo &&
levels_needed >= geqo_threshold" condition is met. Besides that, I
don't really know if there's any way. You could try editing the
geqo_seed and seeing if the plan changes, but if it does not, then
that does not mean the geqo was not used, so doing it that way could
be quite error-prone. You'd only be able to tell the geqo was being
used if you could confirm that changing geqo_seed did change the plan.
(And you could be certain the plan did not change for some other
reason like an auto-analyze).
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2019-10-09 18:42:31 | Re: Modification of data in base folder and very large tables |
Previous Message | Tom Lane | 2019-10-09 16:07:47 | Re: Query slows when used with view |