From 238fb0342e3762764ee5a0664a1c24e81c68267b Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Mon, 25 Apr 2005 15:35:32 +0000 Subject: Update description: < * Allow ORDER BY ... LIMIT 1 to select high/low value without sort or > * Allow ORDER BY ... LIMIT # to select high/low value without sort or 868c868 < Right now, if no index exists, ORDER BY ... LIMIT 1 requires we sort > Right now, if no index exists, ORDER BY ... LIMIT # requires we sort 870a871 > MIN/MAX already does this, but not for LIMIT > 1. --- doc/src/FAQ/TODO.html | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'doc/src') diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html index a4b407d153b..eba1ec7576a 100644 --- a/doc/src/FAQ/TODO.html +++ b/doc/src/FAQ/TODO.html @@ -8,7 +8,7 @@

PostgreSQL TODO List

Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
-Last updated: Mon Apr 25 09:03:30 EDT 2005 +Last updated: Mon Apr 25 11:35:24 EDT 2005

The most recent version of this document can be viewed at
http://www.postgresql.org/docs/faqs.TODO.html. @@ -787,11 +787,12 @@ first.

Add missing optimizer selectivities for date, r-tree, etc -
Allow ORDER BY ... LIMIT 1 to select high/low value without sort or +
Allow ORDER BY ... LIMIT # to select high/low value without sort or index using a sequential scan for highest/lowest values -
Right now, if no index exists, ORDER BY ... LIMIT 1 requires we sort +
Right now, if no index exists, ORDER BY ... LIMIT # requires we sort all values to return the high/low value. Instead The idea is to do a sequential scan to find the high/low value, thus avoiding the sort. + MIN/MAX already does this, but not for LIMIT > 1.
Precompile SQL functions to avoid overhead
Create utility to compute accurate random_page_cost value -- cgit v1.2.3