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

Commit238fb03

Browse files
committed
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 or868c868< Right now, if no index exists, ORDER BY ... LIMIT 1 requires we sort> Right now, if no index exists, ORDER BY ... LIMIT # requires we sort870a871> MIN/MAX already does this, but not for LIMIT > 1.
1 parent61cf535 commit238fb03

File tree

2 files changed

+8
-6
lines changed

2 files changed

+8
-6
lines changed

‎doc/TODO

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
PostgreSQL TODO List
33
====================
44
Current maintainer:Bruce Momjian (pgman@candle.pha.pa.us)
5-
Last updated:Mon Apr 2509:03:30 EDT 2005
5+
Last updated:Mon Apr 2511:35:24 EDT 2005
66

77
The most recent version of this document can be viewed at
88
http://www.postgresql.org/docs/faqs.TODO.html.
@@ -862,12 +862,13 @@ Optimizer / Executor
862862
====================
863863

864864
* Add missing optimizer selectivities for date, r-tree, etc
865-
* Allow ORDER BY ... LIMIT1 to select high/low value without sort or
865+
* Allow ORDER BY ... LIMIT# to select high/low value without sort or
866866
index using a sequential scan for highest/lowest values
867867

868-
Right now, if no index exists, ORDER BY ... LIMIT1 requires we sort
868+
Right now, if no index exists, ORDER BY ... LIMIT# requires we sort
869869
all values to return the high/low value. Instead The idea is to do a
870870
sequential scan to find the high/low value, thus avoiding the sort.
871+
MIN/MAX already does this, but not for LIMIT > 1.
871872

872873
* Precompile SQL functions to avoid overhead
873874
* Create utility to compute accurate random_page_cost value

‎doc/src/FAQ/TODO.html

Lines changed: 4 additions & 3 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:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</a>)<br/>
11-
Last updated: Mon Apr 2509:03:30 EDT 2005
11+
Last updated: Mon Apr 2511:35:24 EDT 2005
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>.
@@ -787,11 +787,12 @@ <h1><a name="section_18">Optimizer / Executor</a></h1>
787787

788788
<ul>
789789
<li>Add missing optimizer selectivities for date, r-tree, etc
790-
</li><li>Allow ORDER BY ... LIMIT1 to select high/low value without sort or
790+
</li><li>Allow ORDER BY ... LIMIT# to select high/low value without sort or
791791
index using a sequential scan for highest/lowest values
792-
<p> Right now, if no index exists, ORDER BY ... LIMIT1 requires we sort
792+
<p> Right now, if no index exists, ORDER BY ... LIMIT# requires we sort
793793
all values to return the high/low value. Instead The idea is to do a
794794
sequential scan to find the high/low value, thus avoiding the sort.
795+
MIN/MAX already does this, but not for LIMIT &gt; 1.
795796
</p>
796797
</li><li>Precompile SQL functions to avoid overhead
797798
</li><li>Create utility to compute accurate random_page_cost value

0 commit comments

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