Re: pg_stat_*_columns? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_stat_*_columns?
Date
Msg-id 65642.1434838544@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_stat_*_columns?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pg_stat_*_columns?  (Robert Haas <robertmhaas@gmail.com>)
Re: pg_stat_*_columns?  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
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?

> 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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: The real reason why TAP testing isn't ready for prime time
Next
From: Tom Lane
Date:
Subject: Re: Inheritance planner CPU and memory usage change since 9.3.2