Re: Stats for inheritance trees

On Tue, Dec 29, 2009 at 9:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.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.)

[ Hack, hack, hack. ]

I'm not quite sure what the correct approach is to making attoptions
available to examine_attribute(), which can't get at them in any very
obvious way because the relation descriptor it gets passed as an
argument only includes the fixed-size portion of each pg_attribute
tuple.  The obvious approaches are:

1. Extract attrelid and attnum from the tuple and issue a syscache
lookup to get the full tuple.
2. Make RelationBuildTupleDesc() parse the attoptions and store them
into a new RelationData member.

I'm leaning toward the latter method.  The upside of that method is
that making attoptions part of the Relation descriptor means that
they'll be conveniently available to all clients of the relcache.  The
downside is that right now, only ANALYZE actually needs to care at the
moment, and yet we're incurring the overhead across the board.  My
thought is that that's OK, but I wonder if anyone thinks it might
cause a measurable performance hit?

WIP patch attached.  Right now this just adds the ability to set and
store attoptions, but doesn't actually do anything useful with them.
No doc changes, no pg_dump support, no psql support, doesn't remove
the SET STATISTICS DISTINCT code.  All these warts will be fixed in a
future version once I decide what to do about the problem mentioned
above.

...Robert