From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mark Cave-Ayland" <m(dot)cave-ayland(at)webbased(dot)co(dot)uk> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: ANALYZE patch for review |
Date: | 2004-02-02 16:54:12 |
Message-ID: | 11001.1075740852@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
"Mark Cave-Ayland" <m(dot)cave-ayland(at)webbased(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2004-02-02 17:02:07 | Re: reading uninitialized buffer |
Previous Message | Mark Cave-Ayland | 2004-02-02 16:31:57 | Re: ANALYZE patch for review |