"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes:
> 2) Should the statistical data for custom types be stored in the
> pg_statistic table, or should it be the responsibility of the custom
> type to store this in separate tables itself?
You had better have a very, very good reason for proposing the latter,
as it will break many things. (For example, the next thing you'll be
wanting is a hook in DROP TABLE so you can clean out your other tables.)
pg_statistic is designed to store multiple kinds of data using the
"kind" flag. If that doesn't seem flexible enough to you, let's talk
about why not, rather than proposing more tables.
> 3) If pg_statistic is the best place to store the data, what would be
> the most appropriate structure to send/receive from the custom analyze
> function? It looks as if VacAttrStats would do the job, although I'm not
> convinced that passing a non-datum/standard C types to a user function
> is a good idea?
The only reason you're bothering with this is so you can feed the data
to custom selectivity routines, no? And those have always used internal
C structs as arguments. So avoiding them for analyze routines seems
pretty pointless. You might as well make the API be exactly that
of compute_minimal_stats/compute_scalar_stats/etc.
Note that I don't think you will be able to get away with just one
routine in the API. You'll need at least two, one that gets invoked at
the "examine_attribute" stage and one at the "compute_stats" stage,
so that you can have some input into how many sample rows get collected.
Everything in examine_attribute past the first couple of tests is really
just as analysis-method-specific as the actual computation.
Actually, looking at this, I recall that the original intention was for
VacAttrStats to be a datatype-independent struct, but the examine
routine could allocate a larger struct of which VacAttrStats is just the
first component; so if you need some private communication between the
two routines, you can have it. You could replace "algcode" with a
function pointer to the stats-computation routine, so that only one
function OID reference is needed in pg_type (pointing to the correct
"examine" routine instead of "compute_stats").
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
