This patch makes some minor improvements to the TODO list:
* add URLs for some TODO items (I think we ought to try to associate
at least one URL with each non-trivial TODO item)
Advertising
* re-add a TODO item for an "estimated count"-like facility
* add a TODO item for considering changing how equality comparisons
treat NaN values, per recent discussion
Barring any objections, I'll apply this to HEAD tomorrow.
-Neil
Index: doc/TODO
===================================================================
RCS file: /home/neilc/postgres/cvs_root/pgsql/doc/TODO,v
retrieving revision 1.2040
diff -c -p -r1.2040 TODO
*** doc/TODO 13 Jan 2007 15:13:44 -0000 1.2040
--- doc/TODO 15 Jan 2007 17:13:59 -0000
*************** Data Types
*** 185,190 ****
--- 185,196 ----
The positive modulus result returned by NUMERICs might be considered
inaccurate, in one sense.
+ * Consider changing equality comparison for numeric, float4, and
+ float8 to treat NaN in a way that is consistent with the
+ IEEE754 standard, perhaps by introducing an IS NAN construct.
+
+ http://archives.postgresql.org/pgsql-hackers/2007-01/msg00597.php
+
* Fix data types where equality comparison isn't intuitive, e.g. box
* Allow user-defined types to specify a type modifier at table creation
time
*************** Functions
*** 341,347 ****
* Add ISO day of week format 'ID' to to_char() where Monday = 1
* Add a field 'isoyear' to extract(), based on the ISO week
* Add SPI_gettypmod() to return the typemod for a TupleDesc
! * Allow inlining of set-returning functions
* Allow SQL-language functions to return results from RETURNING queries
--- 347,353 ----
* Add ISO day of week format 'ID' to to_char() where Monday = 1
* Add a field 'isoyear' to extract(), based on the ISO week
* Add SPI_gettypmod() to return the typemod for a TupleDesc
! * Implement inlining of set-returning functions defined in SQL
* Allow SQL-language functions to return results from RETURNING queries
*************** Indexes
*** 928,933 ****
--- 934,941 ----
several hash buckets could be stored on a single page and greater
granularity used for the hash algorithm.
+ http://archives.postgresql.org/pgsql-hackers/2004-06/msg00168.php
+
o Consider sorting hash buckets so entries can be found using a
binary search, rather than a linear scan
*************** Cache Usage
*** 972,977 ****
--- 980,992 ----
faster than a sequential scan it must avoid access to the heap
to obtain tuple visibility information.
+ * Provide a way to calculate an "estimated COUNT(*)"
+
+ Perhaps by using the optimizer's cardinality estimates or random
+ sampling.
+
+ http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php
+
* Allow data to be pulled directly from indexes
Currently indexes do not have enough tuple visibility information
*************** Locking
*** 1075,1080 ****
--- 1090,1098 ----
* Fix priority ordering of read and write light-weight locks (Neil)
+ http://archives.postgresql.org/pgsql-hackers/2004-11/msg00893.php
+ http://archives.postgresql.org/pgsql-hackers/2004-11/msg00905.php
+
Startup Time Improvements
=========================
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
