Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commitbe05edd

Browse files
committed
Tweak planner to use OFFSET+LIMIT, not just LIMIT, as estimate of the
portion of the query result that will be retrieved. As far as I couldtell, the consensus was that we should let the planner do the best itcan with a LIMIT query, and require the user to add ORDER BY if hewants consistent results from different LIMIT values.
1 parent07c495f commitbe05edd

File tree

1 file changed

+32
-16
lines changed

1 file changed

+32
-16
lines changed

‎src/backend/optimizer/plan/planner.c

Lines changed: 32 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
*
99
*
1010
* IDENTIFICATION
11-
* $Header: /cvsroot/pgsql/src/backend/optimizer/plan/planner.c,v 1.75 2000/02/15 20:49:18 tgl Exp $
11+
* $Header: /cvsroot/pgsql/src/backend/optimizer/plan/planner.c,v 1.76 2000/02/21 01:13:04 tgl Exp $
1212
*
1313
*-------------------------------------------------------------------------
1414
*/
@@ -291,30 +291,46 @@ union_planner(Query *parse,
291291
/* Initial assumption is we need all the tuples */
292292
tuple_fraction=0.0;
293293
/*
294-
* Check for a LIMIT.
295-
*
296-
* For now, we deliberately ignore the OFFSET clause, so that
297-
* queries with the same LIMIT and different OFFSETs will get
298-
* the same queryplan and therefore generate consistent results
299-
* (to the extent the planner can guarantee that, anyway).
300-
* XXX Perhaps it would be better to use the OFFSET too, and tell
301-
* users to specify ORDER BY if they want consistent results
302-
* across different LIMIT queries.
294+
* Check for a LIMIT clause.
303295
*/
304296
if (parse->limitCount!=NULL)
305297
{
306298
if (IsA(parse->limitCount,Const))
307299
{
308-
Const*ccount= (Const*)parse->limitCount;
309-
tuple_fraction= (double) ((int) (ccount->constvalue));
310-
/* the constant can legally be either 0 ("ALL") or a
311-
* positive integer; either is consistent with our
312-
* conventions for tuple_fraction.
300+
Const*limitc= (Const*)parse->limitCount;
301+
intcount= (int) (limitc->constvalue);
302+
303+
/*
304+
* The constant can legally be either 0 ("ALL") or a
305+
* positive integer. If it is not ALL, we also need
306+
* to consider the OFFSET part of LIMIT.
313307
*/
308+
if (count>0)
309+
{
310+
tuple_fraction= (double)count;
311+
if (parse->limitOffset!=NULL)
312+
{
313+
if (IsA(parse->limitOffset,Const))
314+
{
315+
intoffset;
316+
317+
limitc= (Const*)parse->limitOffset;
318+
offset= (int) (limitc->constvalue);
319+
if (offset>0)
320+
tuple_fraction+= (double)offset;
321+
}
322+
else
323+
{
324+
/* It's a PARAM ... punt ... */
325+
tuple_fraction=0.10;
326+
}
327+
}
328+
}
314329
}
315330
else
316331
{
317-
/* It's a PARAM ... don't know exactly what the limit
332+
/*
333+
* COUNT is a PARAM ... don't know exactly what the limit
318334
* will be, but for lack of a better idea assume 10%
319335
* of the plan's result is wanted.
320336
*/

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp