| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| 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 16:40:50 |
| Message-ID: | 621.1434904850@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> 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.
I think we should go into this with the mindset of re-using the DSM
infrastructure, rather than inventing a new mechanism of uncertain
portability.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2015-06-21 16:48:10 | Re: Backpatch src/test/modules to 9.3? |
| Previous Message | Andres Freund | 2015-06-21 16:32:25 | Backpatch src/test/modules to 9.3? |