mirror of
				https://github.com/postgres/postgres.git
				synced 2025-10-31 00:03:57 -04:00 
			
		
		
		
	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.
This commit is contained in:
		
							parent
							
								
									61cf53516e
								
							
						
					
					
						commit
						238fb0342e
					
				
							
								
								
									
										7
									
								
								doc/TODO
									
									
									
									
									
								
							
							
						
						
									
										7
									
								
								doc/TODO
									
									
									
									
									
								
							| @ -2,7 +2,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. | ||||
| @ -862,12 +862,13 @@ Optimizer / Executor | ||||
| ==================== | ||||
| 
 | ||||
| * 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 | ||||
|  | ||||
| @ -8,7 +8,7 @@ | ||||
| <body bgcolor="#FFFFFF" text="#000000" link="#FF0000" vlink="#A00000" alink="#0000FF"> | ||||
| <h1><a name="section_1">PostgreSQL TODO List</a></h1> | ||||
| <p>Current maintainer:     Bruce Momjian (<a href="mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</a>)<br/> | ||||
| Last updated:           Mon Apr 25 09:03:30 EDT 2005 | ||||
| Last updated:           Mon Apr 25 11:35:24 EDT 2005 | ||||
| </p> | ||||
| <p>The most recent version of this document can be viewed at<br/> | ||||
| <a href="http://www.postgresql.org/docs/faqs.TODO.html">http://www.postgresql.org/docs/faqs.TODO.html</a>. | ||||
| @ -787,11 +787,12 @@ first. | ||||
| 
 | ||||
| <ul> | ||||
|   <li>Add missing optimizer selectivities for date, r-tree, etc | ||||
|   </li><li>Allow ORDER BY ... LIMIT 1 to select high/low value without sort or | ||||
|   </li><li>Allow ORDER BY ... LIMIT # to select high/low value without sort or | ||||
|   index using a sequential scan for highest/lowest values | ||||
| <p>  Right now, if no index exists, ORDER BY ... LIMIT 1 requires we sort  | ||||
| <p>  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. | ||||
| </p> | ||||
|   </li><li>Precompile SQL functions to avoid overhead | ||||
|   </li><li>Create utility to compute accurate random_page_cost value | ||||
|  | ||||
		Loading…
	
	
			
			x
			
			
		
	
		Reference in New Issue
	
	Block a user