Where can I get the number of plans that considered by Planner?
Where can I add a integer counter to count the plans considered by planner.
In my opinion, it is in the src/backend/optimizer/path directorty.
=?UTF-8?B?57qq5pmT5pum?= <sheepjxx@gmail.com> writes:
Where can I add a integer counter to count the plans considered by planner.
Well, you could count the number of calls to add_path, but a path is
hardly the same thing as a complete plan.
regards, tom lane
Since I also need to consider gego, is this the best way to do it?
2009/9/30 Tom Lane <tgl@sss.pgh.pa.us>
Show quoted text
=?UTF-8?B?57qq5pmT5pum?= <sheepjxx@gmail.com> writes:
Where can I add a integer counter to count the plans considered by
planner.
Well, you could count the number of calls to add_path, but a path is
hardly the same thing as a complete plan.regards, tom lane
On Sat, Oct 03, 2009 at 04:20:59PM +1000, ????????? wrote:
Since I also need to consider gego, is this the best way to do it?
I think you need to be clearer about what you're trying to count.
Consider a nestjoin plan where:
- For the inner side it considers 7 paths and throws away 4.
- For the outer side it considers 6 paths and throws away 2.
Do you want the number 3*4=12 or 7*6=42? Or something in between (what
if in addition to a nestjoin plan otther possibilities are possible).
As you can see, you can't talk about complete plans because they don't
exist until right at the end, until then it's just considering how to
combine different paths in sensible ways.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
Please line up in a tree and maintain the heap invariant while
boarding. Thank you for flying nlogn airlines.
What I want to count is the number of plans that have been considered
cheapest_path. Since if a path is considered to be a cheapest_path, the
postgres optimizer need to spent time on comparison. I think this is what I
want.
2009/10/4 Martijn van Oosterhout <kleptog@svana.org>
Show quoted text
On Sat, Oct 03, 2009 at 04:20:59PM +1000, ????????? wrote:
Since I also need to consider gego, is this the best way to do it?
I think you need to be clearer about what you're trying to count.
Consider a nestjoin plan where:- For the inner side it considers 7 paths and throws away 4.
- For the outer side it considers 6 paths and throws away 2.Do you want the number 3*4=12 or 7*6=42? Or something in between (what
if in addition to a nestjoin plan otther possibilities are possible).As you can see, you can't talk about complete plans because they don't
exist until right at the end, until then it's just considering how to
combine different paths in sensible ways.Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/Please line up in a tree and maintain the heap invariant while
boarding. Thank you for flying nlogn airlines.-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)iD8DBQFKyIiaIB7bNG8LQkwRAklcAJsFBOQE/xAscZm0ok4WwxVh+C6x8ACfYuNz
G4GpDdQ4IuTXGWc5QHhD5dc=
=ynTH
-----END PGP SIGNATURE-----
Is it a reasonable idea to add a counter to set_cheapest? I think this
function evaluate the cheapest path. Therefore, it means how many complete
plans have been considered, doesn't it?
2009/10/12 纪晓曦 <sheepjxx@gmail.com>
Show quoted text
What I want to count is the number of plans that have been considered
cheapest_path. Since if a path is considered to be a cheapest_path, the
postgres optimizer need to spent time on comparison. I think this is what I
want.2009/10/4 Martijn van Oosterhout <kleptog@svana.org>
On Sat, Oct 03, 2009 at 04:20:59PM +1000, ????????? wrote:
Since I also need to consider gego, is this the best way to do it?
I think you need to be clearer about what you're trying to count.
Consider a nestjoin plan where:- For the inner side it considers 7 paths and throws away 4.
- For the outer side it considers 6 paths and throws away 2.Do you want the number 3*4=12 or 7*6=42? Or something in between (what
if in addition to a nestjoin plan otther possibilities are possible).As you can see, you can't talk about complete plans because they don't
exist until right at the end, until then it's just considering how to
combine different paths in sensible ways.Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/Please line up in a tree and maintain the heap invariant while
boarding. Thank you for flying nlogn airlines.-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)iD8DBQFKyIiaIB7bNG8LQkwRAklcAJsFBOQE/xAscZm0ok4WwxVh+C6x8ACfYuNz
G4GpDdQ4IuTXGWc5QHhD5dc=
=ynTH
-----END PGP SIGNATURE-----
=?UTF-8?B?57qq5pmT5pum?= <sheepjxx@gmail.com> writes:
Is it a reasonable idea to add a counter to set_cheapest?
You can try it but I think you'll find it's not terribly useful.
That will effectively just give you a count of the number of join
combinations that were considered (plus the number of base relations).
regards, tom lane
Yeah, the problem is when I test large join, the plan considered by geqo is
large than path. (3000+ vs 500+). However, the time used in optimizer of
geqo is 1/4 of path. By the way, I use the same query.
Another thing is for the join of 2 tables, geqo consider 60-90 plans.
In general, I think for large join, geqo consider less plans than path, am
I right?
2009/10/13 Tom Lane <tgl@sss.pgh.pa.us>
Show quoted text
=?UTF-8?B?57qq5pmT5pum?= <sheepjxx@gmail.com> writes:
Is it a reasonable idea to add a counter to set_cheapest?
You can try it but I think you'll find it's not terribly useful.
That will effectively just give you a count of the number of join
combinations that were considered (plus the number of base relations).regards, tom lane