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 по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Block-level CRC checks
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Block-level CRC checks