"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes: > Yup indeed. Please find enclosed the latest version of the analyze patch > taking into account all the things we have discussed in the thread.
I've reviewed and applied this with some small changes. You did a good job --- the only things you missed AFAICS were pg_dump support and documentation. I changed the API slightly for the typanalyze function and the compute_stats subroutine. I don't think it's necessary or appropriate to pass in the Relation pointer to typanalyze; that simplifies its signature to a single INTERNAL parameter. (If we did want to pass the Relation, I'd be inclined to make it a field in VacAttrStats.) Also I tweaked compute_stats so that the attribute number of the column is passed explicitly. I foresee needing this for functional-index stats gathering --- it's likely that the accumulated sample rows will be built on the fly and will have a tupdesc that includes both the main table rows and the functional index columns. So compute_stats shouldn't assume that the nominal column number is the right thing to use to extract the column it wants. > I also altered the examine_attribute() to allow the user-defined > function to check attstattarget for the column manually (in case they > want to do something special with minus or zero values), As I've committed it, the convention that zero means "no stats" is enforced by examine_attribute(), but the typanalyze function is responsible for deciding what a negative value means. Seem reasonable? Also, I put the following documentation about "kind" values into pg_statistic.h. /* * The present allocation of "kind" codes is: * * 1-99: reserved for assignment by the core PostgreSQL project * (values in this range will be documented in this file) * 100-199: reserved for assignment by the PostGIS project * (values to be documented in PostGIS documentation) * 200-9999: reserved for future public assignments * * For private use you may choose a "kind" code at random in the range * 10000-30000. However, for code that is to be widely disseminated it is * better to obtain a publicly defined "kind" code by request from the * PostgreSQL Global Development Group. */ regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html