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)
* 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