On 7-1-2014 20:21, Jim Starkey wrote: > On 1/7/2014 1:14 PM, Simonov Denis wrote: >>> Why it have to have fixed position? Cannot btyacc syntax parser handle a >>> clause anywhere?.. >> >> Course parser can parse and tips from various places, but I look at it >> from the perspective of the application developer. It is much easier to >> remove or comment out the tips when they are concentrated in one place >> request, than to seek out across a query that may not be quite small. > > Semantically significant comments are such a mistake. The fact that > other system use them don't make them a good idea. Comments are > comments and are meant to be ignored. What are you supposed to do if > you see a syntax or semantic error is a hint-comment? Given an error? > Guess at the users intent? Quietly ignore it?
You are responding to a post that says having it in one place makes it easy to comment out (as in: disable), not about having semantically significant comments. > FIRST has some real problems. You could do it with the non-standard > Firebird FIRST, but extending the SQL standard clauses to allow the > number of rows to be omitted is a blatant violation of the standard, > which is not a good idea. > > The FIRST clause in GDML goes all the way back to Datatrieve-11 V1.0. > It's extremely convenient for interactive use. I used it to signal > navigational index walking in, maybe, 1986 or 1987 for dBase emulation > for Ashton-Tate. So we're not really talking semantics here, just the > syntax. "FIRST <a large number>" does the trick. It works as well with > standard SQL as Firebird SQL. I haven't a clue why the optimizer isn't > handling it correctly, if, in fact, it isn't. I agree that SELECT FIRST n should be an indication for the optimizer to use a specific optimization, however I'd like to reiterate my position that it isn't a hint, it describes an expected output. The fact that the optimizer will (or should) optimize it in a specific way does not mean you should abuse also it to get the optimizer to use a specific optimization. It can lead to hard to find bugs in the future, for example if you used SELECT FIRST 1000000 to trick the optimizer (aka "I am never going to have more than a million"), fun ensues when against all expectations you do pass the 1 million mark. And yes, you can take the position that hints make for lazy optimizers, on the other hand sometimes optimizers simply make bad plans that I'd like to address 'now', and not 10 years down the road when Oracle, Microsoft or the Firebird team finally finds time to do something with my bug report. In my mind, a specific syntax for optimization hints is better than abusing features that will trigger specific optimizer behaviour: a separate syntax makes explicit that it is an optimization (attempt), and future maintainers of your code won't think you were an idiot for abusing 'feature X' in a way that doesn't make sense, and they (or you) will be better aware of consequences of changing it. And yes, you could document the abuse, but I think most people forget to comment or will think it obvious. With the SQL Server syntax optimizing for retrieval of the first 150 rows is done with: SELECT ... FROM someTable ... OPTION (FAST 150) It also contains an interesting option (OPTIMIZE FOR) for 'helping' the optimizer decide on a plan by providing exemplar values for parameters. Mark -- Mark Rotteveel ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
