Re: pg_stat_*_columns?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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-21 15:53:36
Message-ID: 20150621155336.GD9243@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-06-20 10:55:03 -0400, Tom Lane wrote:
> 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.

We could also just mmap() the stats file into memory in various
processes. With a bit care it should be quite possible to only mmap a
subsets of the file at once, taking care of the address space issues.

There'll be some interesting problems to solve for both DSM and mmap
based solutions to make the locking work nicely. I guess most of it
should be doable quite sensibly using atomics; but the emulation on
older platforms might mean that we'd need to serialize at restarts.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-06-21 16:29:19 Re: Inheritance planner CPU and memory usage change since 9.3.2
Previous Message Magnus Hagander 2015-06-21 15:43:34 Re: pg_stat_*_columns?