Skip site navigation (1) Skip section navigation (2)

Re: Stats for inheritance trees

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Stats for inheritance trees
Date: 2009-12-30 02:05:05
Message-ID: 603c8f070912291805n1a734391p2cc0af3b0187146b@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Dec 29, 2009 at 8:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Having separate properties for regular attdistinct and inherited
>> attdistinct seems fairly worthwhile, but I share your lack of
>> enthusiasm for solving the problem by adding more columns to
>> pg_attribute.  One possibility would be to create a new system catalog
>> to hold "non-critical" information on pg_attribute properties - that
>> is, anything that isn't likely to be needed to plan and execute
>> ordinary queries.  attstattarget and attdistinct would certainly
>> qualify, and there may be others.
>
> Hmm... offhand it seems like all of these columns would be potential
> candidates for pushing out to a secondary catalog:
>
>  attstattarget | integer   | not null
>  attdistinct   | real      | not null
>  attndims      | integer   | not null
>  attislocal    | boolean   | not null
>  attinhcount   | integer   | not null
>  attacl        | aclitem[] |
>
> But even with another ndistinct column, that barely amounts to 2 dozen
> bytes saved.  Maybe it's worth the trouble in order to shave space from
> tuple descriptors, but it seems pretty marginal.

Maybe.  I would think that attacl[] would need to be consulted
frequently enough that you'd want to have it around, but maybe not.

> (Actually, it looks to me like we could lose attndims altogether with
> little pain ...)
>
>> A second possibility would be to generalize the concept of reloptions
>> to apply to columns.
>
> Hm ... the base assumption in the reloptions code is that the user is
> free to twiddle all the values.  attdistinct and attstattarget might fit
> that bill but none of the other stuff would, so we couldn't go very far
> in terms of pushing things out of the core attributes.  Still there's
> some attraction in not having to alter pg_attribute the next time we
> think of something like these.

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.

...Robert

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-12-30 02:12:10
Subject: Re: Stats for inheritance trees
Previous:From: Robert HaasDate: 2009-12-30 01:57:35
Subject: Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group