On Thu, 2008-04-03 at 16:45 +0200, Hell, Robert wrote: > This patch adds a GUC parameter for tuple_fraction of cursors (discussed > earlier here: > http://archives.postgresql.org/pgsql-performance/2008-04/msg00018.php). > By setting this parameter the planner's favor to use fast-start plans > for cursors can be affected.
I think this patch looks OK coding-wise, but not tested, yet. If we did apply this patch it would need significantly more documentation, probably examples and the like. But I think writing that docs would open up a can of worms, hence copying -hackers. Other RDBMS allow users to specify whether they want fast-start or all-data plans. We should discuss whether we want to set the fraction directly or whether we should have 2 (or more) specific settings such as "fast" and "all". Also, if we did have this parameter then I don't think it should be included in postgresql.conf. I don't see any need to change the default setting for *all* cursors, but I can see the need to change the cursor fraction for *one* specific query. Which raises wider issues. * We could add to DECLARE syntax that says something like OPTIMIZE FOR FIRST ROWS or OPTIMIZE FOR ALL ROWS. But our policy AIUI is that we do not want to further decorate SQL Standard commands. * We've said here http://www.postgresql.org/docs/faqs.TODO.html that we "Don't want hints". If that's what we really think, then this patch must surely be rejected because its a hint... That isn't my view. I *now* think we do need hints of various kinds. Decorating queries with *all* necessary information is not always good, but there are some kinds of information that *do* belong on specific queries. The cursor fraction is a great example of information that really does live on a specific query. But in a wider sense, I think support of hints is actually the only way long term of making large applications work within a reasonable timeframe and cost. If we change information at the database object level in order to correct one issue, we are likely to find that more problems are raised elsewhere. Same thing is true of altering optimiser cost models. Few users can wait 2 years while we solve the problem and fix it permanently, or even a few days while they resolve the inner workings of the planner and work out how to re-write it. I had spoken strongly against hints for general use in Postgres previously. Many attendees on recent PostgreSQL performance courses have successfully argued in favour of hints and as a result my viewpoint is now changed. Though we need a central no-hints-allowed GUC for those cases where application programmers need restraining... I think we need Hints. (And not this patch, sorry about that, Robert). (This could well lead to me losing work doing performance tuning, though I believe its the wish of the majority that we should support hints). -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
