Re: pg_stat_*_columns? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_stat_*_columns?
Date
Msg-id 44902.1434812103@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_stat_*_columns?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pg_stat_*_columns?  (Magnus Hagander <magnus@hagander.net>)
Re: pg_stat_*_columns?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Jun 20, 2015 at 10:12 AM, Joel Jacobson <joel@trustly.com> wrote:
>> I guess it
>> primarily depends on how much of the new code that would need to be
>> rewritten, if the collector is optimized/rewritten in the future?

> I don't think that's really the issue.  It's more that I think it
> would be the extra data would be likely to cause real pain for users.

Yes.  The stats data already causes real pain.

> FWIW, I tend to think that the solution here has less to do with
> splitting the data up into more files and more to do with rethinking
> the format.

I dunno that tweaking the format would accomplish much.  Where I'd love
to get to is to not have to write the data to disk at all (except at
shutdown).  But that seems to require an adjustable-size shared memory
block, and I'm not sure how to do that.  One idea, if the DSM stuff
could be used, is to allow the stats collector to allocate multiple
DSM blocks as needed --- but how well would that work on 32-bit
machines?  I'd be worried about running out of address space.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: pretty bad n_distinct estimate, causing HashAgg OOM on TPC-H
Next
From: Magnus Hagander
Date:
Subject: Re: pg_stat_*_columns?