Re: Stats for inheritance trees

On Tue, Dec 29, 2009 at 9:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Yep.  It would also lower the barrier to future innovations of that
>> type, which would be a good thing, IMO.  Unfortunately we'd likely
>> need to continue to support the existing syntax at least for
>> attstattarget, which is kind of a bummer, but seems managable.  I
>> think we could throw over the syntax for ALTER TABLE ... ADD
>> STATISTICS DISTINCT since it is an 8.5-ism.
>
> Yeah --- if we think we might want to do this, now is the time,
> before we're stuck with supporting that syntax.  (I was thinking
> earlier today that attdistinct was already in 8.4, but it's not.)

I am just starting to look at this now. One of the questions I have
is what we should call the options. We could call the regular options
something like "ndistinct" or "distinct", but I'm not too sure what to
call the "for-inheritance-trees" version of that. I suppose we could
just use the familiar "inh" prefix and call it "inhndistinct", but
that looks suspiciously like gobbledygook. Someone's understanding of
just what that is supposed to mean might be a little... indistinct (ba
dum).

Another option would be to call it "inherits_ndistinct", or something
like that, which seems a little more readable, but not great: I don't
think there's going to be any getting around the need to RTFM before
setting these parameters.

In terms of syntax, I'm thinking something like:

ALTER TABLE name ALTER COLUMN column SET ( column_parameter = value [, ...] )

I am also very tempted before beginning this work to rename
reloptions.c to options.c or genoptions.c or somesuch. If we're going
to use it for relations, attributes, and tablespaces, chances are good
we're going to use it for other things, too. The FDW stuff is already
borrowing from it as well.

...Robert