Skip site navigation (1) Skip section navigation (2)

Re: Why our counters need to be time-based WAS: WIP: cross column correlation ...

From: Michael Glaesemann <grzm(at)seespotcode(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Why our counters need to be time-based WAS: WIP: cross column correlation ...
Date: 2011-02-28 19:37:23
Message-ID: 9F3F19CE-5C8E-4B1E-8D32-E8CA593452EC@seespotcode.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On Feb 28, 2011, at 14:31, Tom Lane wrote:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Feb 28, 2011 at 1:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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




In response to

Responses

pgsql-hackers by date

Next:From: Marko TiikkajaDate: 2011-02-28 19:39:17
Subject: Re: Review: Fix snapshot taking inconsistencies
Previous:From: Tom LaneDate: 2011-02-28 19:36:10
Subject: Re: Review: Fix snapshot taking inconsistencies

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group