Hi,
On 06/21/2015 12:15 AM, Tom Lane wrote:
Robert Haas <robertmh...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
