File tree 2 files changed +15
-2
lines changed 2 files changed +15
-2
lines changed Original file line number Diff line number Diff line change 2
2
PostgreSQL TODO List
3
3
====================
4
4
Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
5
- Last updated: Sun Apr 24 21:42:27 EDT 2005
5
+ Last updated: Mon Apr 25 09:03:30 EDT 2005
6
6
7
7
The most recent version of this document can be viewed at
8
8
http://www.postgresql.org/docs/faqs.TODO.html.
@@ -862,6 +862,13 @@ Optimizer / Executor
862
862
====================
863
863
864
864
* Add missing optimizer selectivities for date, r-tree, etc
865
+ * Allow ORDER BY ... LIMIT 1 to select high/low value without sort or
866
+ index using a sequential scan for highest/lowest values
867
+
868
+ Right now, if no index exists, ORDER BY ... LIMIT 1 requires we sort
869
+ all values to return the high/low value. Instead The idea is to do a
870
+ sequential scan to find the high/low value, thus avoiding the sort.
871
+
865
872
* Precompile SQL functions to avoid overhead
866
873
* Create utility to compute accurate random_page_cost value
867
874
* Improve ability to display optimizer analysis using OPTIMIZER_DEBUG
Original file line number Diff line number Diff line change 8
8
< body bgcolor ="#FFFFFF " text ="#000000 " link ="#FF0000 " vlink ="#A00000 " alink ="#0000FF ">
9
9
< h1 > < a name ="section_1 "> PostgreSQL TODO List</ a > </ h1 >
10
10
< p > Current maintainer: Bruce Momjian (< a href ="mailto:pgman@candle.pha.pa.us "> pgman@candle.pha.pa.us</ a > )< br />
11
- Last updated: Sun Apr 24 21:42:27 EDT 2005
11
+ Last updated: Mon Apr 25 09:03:30 EDT 2005
12
12
</ p >
13
13
< p > The most recent version of this document can be viewed at< br />
14
14
< a href ="http://www.postgresql.org/docs/faqs.TODO.html "> http://www.postgresql.org/docs/faqs.TODO.html</ a > .
@@ -787,6 +787,12 @@ <h1><a name="section_18">Optimizer / Executor</a></h1>
787
787
788
788
< ul >
789
789
< li > Add missing optimizer selectivities for date, r-tree, etc
790
+ </ li > < li > Allow ORDER BY ... LIMIT 1 to select high/low value without sort or
791
+ index using a sequential scan for highest/lowest values
792
+ < p > Right now, if no index exists, ORDER BY ... LIMIT 1 requires we sort
793
+ all values to return the high/low value. Instead The idea is to do a
794
+ sequential scan to find the high/low value, thus avoiding the sort.
795
+ </ p >
790
796
</ li > < li > Precompile SQL functions to avoid overhead
791
797
</ li > < li > Create utility to compute accurate random_page_cost value
792
798
</ li > < li > Improve ability to display optimizer analysis using OPTIMIZER_DEBUG
You can’t perform that action at this time.
0 commit comments