1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00

Fix some bogosities in the code that deals with estimating the fraction

of tuples we are going to retrieve from a sub-SELECT.  Must have been
half asleep when I did this code the first time :-(
This commit is contained in:
Tom Lane
2000-03-14 02:23:15 +00:00
parent a1642089bf
commit 6217a8c7ba
3 changed files with 42 additions and 29 deletions

View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/backend/optimizer/plan/planner.c,v 1.76 2000/02/21 01:13:04 tgl Exp $
* $Header: /cvsroot/pgsql/src/backend/optimizer/plan/planner.c,v 1.77 2000/03/14 02:23:15 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -360,11 +360,14 @@ union_planner(Query *parse,
* In GROUP BY mode, we have the little problem that we don't
* really know how many input tuples will be needed to make a
* group, so we can't translate an output LIMIT count into an
* input count. For lack of a better idea, assume 10% of the
* input count. For lack of a better idea, assume 25% of the
* input data will be processed if there is any output limit.
* However, if the caller gave us a fraction rather than an
* absolute count, we can keep using that fraction (which amounts
* to assuming that all the groups are about the same size).
*/
if (tuple_fraction > 0.0)
tuple_fraction = 0.10;
if (tuple_fraction >= 1.0)
tuple_fraction = 0.25;
/*
* If both GROUP BY and ORDER BY are specified, we will need
* two levels of sort --- and, therefore, certainly need to
@ -386,11 +389,10 @@ union_planner(Query *parse,
{
/*
* SELECT DISTINCT, like GROUP, will absorb an unpredictable
* number of input tuples per output tuple. So, fall back to
* our same old 10% default...
* number of input tuples per output tuple. Handle the same way.
*/
if (tuple_fraction > 0.0)
tuple_fraction = 0.10;
if (tuple_fraction >= 1.0)
tuple_fraction = 0.25;
}
/* Generate the (sub) plan */