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

Commit71f8127

Browse files
committed
Done:
> * -Allow ORDER BY ... LIMIT # to select high/low value without sort or<< 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.<
1 parentd2a4a40 commit71f8127

File tree

2 files changed

+4
-15
lines changed

2 files changed

+4
-15
lines changed

‎doc/TODO

Lines changed: 2 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
PostgreSQL TODO List
33
====================
44
Current maintainer:Bruce Momjian (bruce@momjian.us)
5-
Last updated:Sun Apr 29 03:17:05 EDT 2007
5+
Last updated:Fri May 4 23:14:29 EDT 2007
66

77
The most recent version of this document can be viewed at
88
http://www.postgresql.org/docs/faqs.TODO.html.
@@ -1361,14 +1361,8 @@ Optimizer / Executor
13611361
====================
13621362

13631363
* Improve selectivity functions for geometric operators
1364-
* Allow ORDER BY ... LIMIT # to select high/low value without sort or
1364+
*-Allow ORDER BY ... LIMIT # to select high/low value without sort or
13651365
index using a sequential scan for highest/lowest values
1366-
1367-
Right now, if no index exists, ORDER BY ... LIMIT # requires we sort
1368-
all values to return the high/low value. Instead The idea is to do a
1369-
sequential scan to find the high/low value, thus avoiding the sort.
1370-
MIN/MAX already does this, but not for LIMIT > 1.
1371-
13721366
* Precompile SQL functions to avoid overhead
13731367
* Create utility to compute accurate random_page_cost value
13741368
* Improve ability to display optimizer analysis using OPTIMIZER_DEBUG

‎doc/src/FAQ/TODO.html

Lines changed: 2 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
<bodybgcolor="#FFFFFF"text="#000000"link="#FF0000"vlink="#A00000"alink="#0000FF">
99
<h1><aname="section_1">PostgreSQL TODO List</a></h1>
1010
<p>Current maintainer: Bruce Momjian (<ahref="mailto:bruce@momjian.us">bruce@momjian.us</a>)<br/>
11-
Last updated:Sun Apr 29 03:17:05 EDT 2007
11+
Last updated:Fri May 4 23:14:29 EDT 2007
1212
</p>
1313
<p>The most recent version of this document can be viewed at<br/>
1414
<ahref="http://www.postgresql.org/docs/faqs.TODO.html">http://www.postgresql.org/docs/faqs.TODO.html</a>.
@@ -1210,13 +1210,8 @@ <h1><a name="section_19">Optimizer / Executor</a></h1>
12101210

12111211
<ul>
12121212
<li>Improve selectivity functions for geometric operators
1213-
</li><li>Allow ORDER BY ... LIMIT # to select high/low value without sort or
1213+
</li><li>-<em>Allow ORDER BY ... LIMIT # to select high/low value without sort or</em>
12141214
index using a sequential scan for highest/lowest values
1215-
<p> Right now, if no index exists, ORDER BY ... LIMIT # requires we sort
1216-
all values to return the high/low value. Instead The idea is to do a
1217-
sequential scan to find the high/low value, thus avoiding the sort.
1218-
MIN/MAX already does this, but not for LIMIT &gt; 1.
1219-
</p>
12201215
</li><li>Precompile SQL functions to avoid overhead
12211216
</li><li>Create utility to compute accurate random_page_cost value
12221217
</li><li>Improve ability to display optimizer analysis using OPTIMIZER_DEBUG

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp