Re: pg_stat_*_columns?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Joel Jacobson <joel(at)trustly(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_stat_*_columns?
Date: 2015-06-20 14:55:03
Message-ID: 44902.1434812103@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Jun 20, 2015 at 10:12 AM, Joel Jacobson <joel(at)trustly(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2015-06-20 14:56:04 Re: pretty bad n_distinct estimate, causing HashAgg OOM on TPC-H
Previous Message Robert Haas 2015-06-20 14:20:26 Re: pg_stat_*_columns?