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 ...  (Josh Berkus <josh@agliodbs.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Review: Fix snapshot taking inconsistencies
Следующее
От: Marko Tiikkaja
Дата:
Сообщение: Re: Review: Fix snapshot taking inconsistencies