Обсуждение: 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.
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>
纪晓曦 <sheepjxx@gmail.com> writes:Well, you could count the number of calls to add_path, but a path is
> Where can I add a integer counter to count the plans considered by planner.
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/ > 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>
On Sat, Oct 03, 2009 at 04:20:59PM +1000, ????????? wrote:I think you need to be clearer about what you're trying to count.
> Since I also need to consider gego, is this the best way to do it?
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>
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>-----BEGIN PGP SIGNATURE-----On Sat, Oct 03, 2009 at 04:20:59PM +1000, ????????? wrote:I think you need to be clearer about what you're trying to count.
> Since I also need to consider gego, is this the best way to do it?
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.
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?
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>
纪晓曦 <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