|
8 | 8 | *
|
9 | 9 | *
|
10 | 10 | * IDENTIFICATION
|
11 |
| - * $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.232 2008/04/17 21:22:14 tgl Exp $ |
| 11 | + * $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.233 2008/05/02 21:26:09 tgl Exp $ |
12 | 12 | *
|
13 | 13 | *-------------------------------------------------------------------------
|
14 | 14 | */
|
|
42 | 42 | #include "utils/syscache.h"
|
43 | 43 |
|
44 | 44 |
|
| 45 | +/* GUC parameter */ |
| 46 | +double cursor_tuple_fraction = DEFAULT_CURSOR_TUPLE_FRACTION; |
| 47 | + |
45 | 48 | /* Hook for plugins to get control in planner() */
|
46 | 49 | planner_hook_type planner_hook = NULL;
|
47 | 50 |
|
@@ -142,11 +145,23 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
|
142 | 145 | {
|
143 | 146 | /*
|
144 | 147 | * We have no real idea how many tuples the user will ultimately FETCH
|
145 |
| - * from a cursor, but it seems a good bet that he doesn't want 'em |
146 |
| - * all. Optimize for 10% retrieval (you gotta better number? Should |
147 |
| - * this be a SETtable parameter?) |
| 148 | + * from a cursor, but it is often the case that he doesn't want 'em |
| 149 | + * all, or would prefer a fast-start plan anyway so that he can |
| 150 | + * process some of the tuples sooner. Use a GUC parameter to decide |
| 151 | + * what fraction to optimize for. |
| 152 | + */ |
| 153 | + tuple_fraction = cursor_tuple_fraction; |
| 154 | + |
| 155 | + /* |
| 156 | + * We document cursor_tuple_fraction as simply being a fraction, |
| 157 | + * which means the edge cases 0 and 1 have to be treated specially |
| 158 | + * here. We convert 1 to 0 ("all the tuples") and 0 to a very small |
| 159 | + * fraction. |
148 | 160 | */
|
149 |
| - tuple_fraction = 0.10; |
| 161 | + if (tuple_fraction >= 1.0) |
| 162 | + tuple_fraction = 0.0; |
| 163 | + else if (tuple_fraction <= 0.0) |
| 164 | + tuple_fraction = 1e-10; |
150 | 165 | }
|
151 | 166 | else
|
152 | 167 | {
|
|
0 commit comments