On Wed, Jun 24, 2015 at 2:03 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Sat, Jun 20, 2015 at 7:20 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> On Sat, Jun 20, 2015 at 10:12 AM, Joel Jacobson <joel@trustly.com> wrote:
>> > Is there any chance the project would accept a patch which adds the
>> > pg_stat_*_columns-feature without first optimizing the collector?
>>
>> I doubt it. It's such a pain point already that massively increasing
>> the amount of data we need to store does not seem like a good plan.
>
> What if the increase only happened for people who turned on
> track_column_usage?
Hmm. You know, what I think would really help is if the column
statistics were stored in different files from the table statistics,
and requested separately. Since these are just there for the DBA, and
wouldn't be used by anything automated, the enormous explosion
wouldn't hurt much.
I'm skeptical of the proposal overall in any event: even if good work
is done to keep the performance impact small, how many DBAs will want
to increase the amount of statistical data by 1-2 orders of magnitude?It's a lot of numbers to keep around for
somethingthat you won't
look at very often and which may not be informative when you do look
at it (e.g. if your queries tend to use SELECT *). But I won't stand
in the way if there's a general consensus that users will find this
useful.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company