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.
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? |