Re: ANALYZE patch for review - Mailing list pgsql-patches

From Tom Lane
Subject Re: ANALYZE patch for review
Date
Msg-id 11001.1075740852@sss.pgh.pa.us
Whole thread Raw
In response to Re: ANALYZE patch for review  ("Mark Cave-Ayland" <m.cave-ayland@webbased.co.uk>)
List pgsql-patches
"Mark Cave-Ayland" <m.cave-ayland@webbased.co.uk> writes:
> So I'd like to propose a slightly different solution. I think that
> examine_attribute() should return a pointer to a custom structure
> containing any information that needs to be passed to the datatype
> specific routine (not the entire VacAttrStats structure), or NULL if the
> column should not be analyzed.

Just a void* you mean?  Sure, we could do that, although it might result
in some duplicated effort.  Another possibility is that analyze.c goes
ahead and creates a VacAttrStats struct (including a void* extension
pointer that it initializes to NULL) and then passes the struct to
examine_attribute, which returns a bool and optionally modifies fields
in the VacAttrStats struct --- in particular the requested-row-count and
extension pointer.  If false is returned then analyze.c just throws away
the VacAttrStats struct instead of including it in its to-do list.

>> If you suppose that the "major" field is the upper bits of
>> the statistics ID value, then this is just a slightly
>> different way of thinking about the range-based allocation
>> method I suggested before.

> I was thinking perhaps in terms of an extra staowner int2 field in
> pg_statistic where the IDs are allocated by the PGDG.

I do not really want to add a field to pg_statistic.  That complicates
matters more than we have a justification to do.  Nor do we have any
reason at this point to think that we need a 2^32 namespace for
statistics kinds.  (If 2^16 ever starts to look cramped, we can just
widen the fields to int4 without introducing any backwards compatibility
issues --- existing code assignments will remain valid.  But I find it
hard to foresee that happening.)

            regards, tom lane

pgsql-patches by date:

Previous
From: "Mark Cave-Ayland"
Date:
Subject: Re: ANALYZE patch for review
Next
From: Neil Conway
Date:
Subject: Re: reading uninitialized buffer