"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

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

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


Reply via email to