Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a - Mailing list pgsql-hackers

From Greg Sabino Mullane
Subject Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a
Date
Msg-id 75f3f169292c8603161d23f5a92012e2@biglumber.com
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Block-level CRC checks
Next
From: Greg Stark
Date:
Subject: Re: Block-level CRC checks