Re: Why our counters need to be time-based WAS: WIP: cross column correlation ...
| От | Michael Glaesemann |
|---|---|
| Тема | Re: Why our counters need to be time-based WAS: WIP: cross column correlation ... |
| Дата | |
| Msg-id | 9F3F19CE-5C8E-4B1E-8D32-E8CA593452EC@seespotcode.net обсуждение исходный текст |
| Ответ на | Re: Why our counters need to be time-based WAS: WIP: cross column correlation ... (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Why our counters need to be time-based WAS: WIP: cross
column correlation ...
|
| Список | pgsql-hackers |
On Feb 28, 2011, at 14:31, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Mon, Feb 28, 2011 at 1:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Ultimately we need to think of a reporting mechanism that's a bit >>> smarter than "rewrite the whole file for any update" ... > >> Well, we have these things called "tables". Any chance of using those? > > Having the stats collector write tables would violate the classical form > of the heisenberg principle (thou shalt avoid having thy measurement > tools affect that which is measured), not to mention assorted practical > problems like not wanting the stats collector to take locks or run > transactions. > > The ideal solution would likely be for the stats collector to expose its > data structures as shared memory, but I don't think we get to do that > under SysV shmem --- it doesn't like variable-size shmem much. Maybe > that's another argument for looking harder into mmap or POSIX shmem, > although it's not clear to me how well either of those fixes that. Spitballing here, but could sqlite be an intermediate, compromise solution? Michael Glaesemann grzm seespotcode net
В списке pgsql-hackers по дате отправления: