From d26559dbf356736923b26704ce76ca820ff3a2b0 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Fri, 4 May 2007 01:13:45 +0000 Subject: Teach tuplesort.c about "top N" sorting, in which only the first N tuples need be returned. We keep a heap of the current best N tuples and sift-up new tuples into it as we scan the input. For M input tuples this means only about M*log(N) comparisons instead of M*log(M), not to mention a lot less workspace when N is small --- avoiding spill-to-disk for large M is actually the most attractive thing about it. Patch includes planner and executor support for invoking this facility in ORDER BY ... LIMIT queries. Greg Stark, with some editorialization by moi. --- src/backend/optimizer/util/pathnode.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'src/backend/optimizer/util/pathnode.c') diff --git a/src/backend/optimizer/util/pathnode.c b/src/backend/optimizer/util/pathnode.c index 6d440001d6b..bd95a0e0e23 100644 --- a/src/backend/optimizer/util/pathnode.c +++ b/src/backend/optimizer/util/pathnode.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/util/pathnode.c,v 1.139 2007/04/21 21:01:45 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/util/pathnode.c,v 1.140 2007/05/04 01:13:44 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -842,7 +842,8 @@ create_unique_path(PlannerInfo *root, RelOptInfo *rel, Path *subpath) cost_sort(&sort_path, root, NIL, subpath->total_cost, rel->rows, - rel->width); + rel->width, + -1.0); /* * Charge one cpu_operator_cost per comparison per input tuple. We assume -- cgit v1.2.3