Re: pg_stat_*_columns?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Joel Jacobson <joel(at)trustly(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_stat_*_columns?
Date: 2015-06-20 22:15:44
Message-ID: 65642.1434838544@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-06-20 22:48:01 Re: Inheritance planner CPU and memory usage change since 9.3.2
Previous Message Michael Paquier 2015-06-20 22:06:55 Re: The real reason why TAP testing isn't ready for prime time