Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a
От | Greg Sabino Mullane |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a |
Дата | |
Msg-id | 75f3f169292c8603161d23f5a92012e2@biglumber.com обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > I don't have a problem with the third explanation ;-). The issue here > is really planner speed relative to execution speed, and that's not so > hardware-sensitive as all that. Yeah, you can plan a 12-join query > way faster than ten years ago, but you can execute it way faster too, > and that's what drives expectations for planning speed. Flat-planning > a 15-way query costs just as much more relative to a 12-way query as > it did ten years ago. Even granted that ratio has stayed the same (and I'd think the planning speed would increase slightly faster than the execution speed, no?), the underlying factor is that there is a magic sweet spot at which we start making tradeoffs for the user. Even if a flat 15-way is the same relative to a 12-way, the absolute numbers should be the prime consideration. In other words, if the average flat plan/execute speed for a 13-way on an average box was 15 seconds in 2000, but 2 seconds in 2009, I would presume that it would now be worth it to consider 13 as needing default geqo coverage. - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation PGP Key: 0x14964AC8 200912040823 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAksZDbkACgkQvJuQZxSWSsjjLgCeKIFStyakHzCQljeqtX2Ie5wi 8fgAoM8ZsXHrVWgmM7UsSP6dKGslQVWK =g6ET -----END PGP SIGNATURE-----
В списке pgsql-hackers по дате отправления: