Hi,
On 06/21/2015 12:15 AM, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> One idea would be to advertise a DSM ID in the main shared memory
>> segment, and have the individual backends read that value and attach
>> to it. When new stats are generated, the stats collector creates a
>> new DSM (which might be bigger or smaller than the old one), writes
>> the new stats in there, and then advertises the new DSM ID in the main
>> shared memory segment. Backends that still have the old segment
>> attached can still use it, and it will go away automatically once they
>> all drop off.
>
> Hmmm. This sounds attractive, but what happens if we fail to create
> a new DSM when needed?
Also, isn't this a potential problem with long-running backends? We
might ultimately end with each backend using a different DSM segment.
>> But I'm not sure how this would work with the new per-database
>> split of the stats file. I don't think it'll work to have one DSM
>> per database; we don't support enough DSMs for that.
>
> AFAIR, that per-database split exists only to try to reduce the
> amount of traffic written to disk. We could lose it cheerfully if the
> communication all happens in shared memory.
Yes, reducing the amount of writes is one of the benefits of the
per-database split, but there are other benefits too. Obviously, it also
reduces the amount of reads (because each backend can read just the
right portion of stats), and reduction of CPU time (because you're
parsing much less data). But I don't see why we couldn't partition the
stats in DSM in a similar manner.
kind regards
--
Tomas Vondra http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
