On Sun, Feb 6, 2011 at 08:17, Greg Smith g...@2ndquadrant.com wrote:
Tomas Vondra wrote:
Because when I create a database, the field is
NULL - that's true. But once I connect to the database, the stats are
updated and the field is set (thanks to the logic in pgstat.c).
OK--so it does what
On 6.2.2011 08:17, Greg Smith wrote:
Below is what changed since the last posted version, mainly as feedback
for Tomas:
-Explained more clearly that pg_stat_reset and
pg_stat_reset_single_counters will both touch the database reset time,
and that it's initialized upon first connection to
Tomas Vondra wrote:
Because when I create a database, the field is
NULL - that's true. But once I connect to the database, the stats are
updated and the field is set (thanks to the logic in pgstat.c).
OK--so it does what I was hoping for, I just didn't test it the right
way. Let's call
Dne 4.2.2011 03:37, Greg Smith napsal(a):
Thinking I should start with why I think this patch is neat...most of
the servers I deal with are up 24x7 minus small amounts of downtime,
presuming everyone does their job right that is. In that environment,
having a starting timestamp for when the
Dne 30.1.2011 23:22, Robert Haas napsal(a):
On Thu, Dec 23, 2010 at 2:41 PM, Tomas Vondra t...@fuzzy.cz wrote:
OK, so here goes the simplified patch - it tracks one reset timestamp
for a background writer and for each database.
I think you forgot the attachment.
Yes, I did. Thanks!
This
Thinking I should start with why I think this patch is neat...most of
the servers I deal with are up 24x7 minus small amounts of downtime,
presuming everyone does their job right that is. In that environment,
having a starting timestamp for when the last stats reset happened lets
you quickly
On Thu, Dec 23, 2010 at 2:41 PM, Tomas Vondra t...@fuzzy.cz wrote:
OK, so here goes the simplified patch - it tracks one reset timestamp
for a background writer and for each database.
I think you forgot the attachment.
Yes, I did. Thanks!
This patch no longer applies. Please update.
--
t...@fuzzy.cz wrote:
- I really am not sure about the changes made in pg_proc.h. I'm not sure
how to assign OIDs to the new functions (I've simply chosen values that
are were not used in this file), and I'm not sure about the other columns
(I've copied and modified another function with the same
Tomas Vondra wrote:
OK, so here goes the simplified patch - it tracks one reset timestamp
for a background writer and for each database.
Adding timestamps like this was something I wanted to do after adding
pg_stat_reset_shared to 9.0, so since you've beaten me to it I'll review
your
Dne 20.12.2010 00:03, Tom Lane napsal(a):
I wrote:
That is not the number of interest. The number of interest is that it's
8 bytes added onto a struct that currently contains 11 of 'em; in other
words a 9% increase in the size of the stats file, and consequently
about a 9% increase in the
2010/12/23 Tomas Vondra t...@fuzzy.cz:
Dne 20.12.2010 00:03, Tom Lane napsal(a):
I wrote:
That is not the number of interest. The number of interest is that it's
8 bytes added onto a struct that currently contains 11 of 'em; in other
words a 9% increase in the size of the stats file, and
Dne 23.12.2010 20:09, Robert Haas napsal(a):
2010/12/23 Tomas Vondra t...@fuzzy.cz:
Dne 20.12.2010 00:03, Tom Lane napsal(a):
I wrote:
That is not the number of interest. The number of interest is that it's
8 bytes added onto a struct that currently contains 11 of 'em; in other
words a 9%
Tomas Vondra t...@fuzzy.cz writes:
I've done several small changes to the patch, namely
- added docs for the functions (in SGML)
- added the same thing for background writer
So I think now it's 'complete' and I'll add it to the commit fest in a
few minutes.
Please split this into
t...@fuzzy.cz writes:
I can prepare an alternative patch, using just per-database timestamps. So
even a reset for a single table/function would set the timestamp for the
whole database.
That seems like quite a bizarre definition. What I was envisioning was
that we'd track only the time of the
On Dec 18, 2010, at 8:51 PM, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
I've done several small changes to the patch, namely
- added docs for the functions (in SGML)
- added the same thing for background writer
So I think now it's 'complete' and I'll add it to the commit fest in a
Dne 19.12.2010 17:26, Tom Lane napsal(a):
That seems like quite a bizarre definition. What I was envisioning was
that we'd track only the time of the last whole-database stats reset.
Well, but that does not quite work. I need is to know whether the
snapshot is 'consistent' i.e. whether I can
Dne 19.12.2010 19:13, Jim Nasby napsal(a):
Is there a reason this info needs to be tracked in the stats table?
I know it's the most obvious place, but since we're worried about the
size of it, what about tracking it in pg_class or somewhere else?
I guess this is the best place for this kind of
Tomas Vondra t...@fuzzy.cz writes:
Dne 19.12.2010 17:26, Tom Lane napsal(a):
That seems like quite a bizarre definition. What I was envisioning was
that we'd track only the time of the last whole-database stats reset.
Well, but that does not quite work. I need is to know whether the
Dne 19.12.2010 20:28, Tom Lane napsal(a):
Tomas Vondra t...@fuzzy.cz writes:
Dne 19.12.2010 17:26, Tom Lane napsal(a):
That seems like quite a bizarre definition. What I was envisioning was
that we'd track only the time of the last whole-database stats reset.
Well, but that does not quite
Tomas Vondra t...@fuzzy.cz writes:
Plus I won't have time to write the other patch for at least a week, so
let's see whether there are serious objections agains the current patch.
If you think this objection is not serious, you're mistaken.
I've never had problems with the pgstat.dat file,
I wrote:
That is not the number of interest. The number of interest is that it's
8 bytes added onto a struct that currently contains 11 of 'em; in other
words a 9% increase in the size of the stats file, and consequently
about a 9% increase in the cost of updating it.
Wups, sorry, I was
Dne 19.12.2010 23:58, Tom Lane napsal(a):
Tomas Vondra t...@fuzzy.cz writes:
Plus I won't have time to write the other patch for at least a week, so
let's see whether there are serious objections agains the current patch.
If you think this objection is not serious, you're mistaken.
I know
Dne 12.12.2010 03:47, Robert Haas napsal(a):
On Sat, Dec 11, 2010 at 4:40 PM, t...@fuzzy.cz wrote:
Hello
you have to respect pg coding style:
a) not too long lines
b) not C++ line comments
OK, thanks for the notice. I've fixed those two problems.
Please add this to the currently-open
Tomas Vondra t...@fuzzy.cz writes:
I've done several small changes to the patch, namely
- added docs for the functions (in SGML)
- added the same thing for background writer
So I think now it's 'complete' and I'll add it to the commit fest in a
few minutes.
Please split this into separate
Hello
you have to respect pg coding style:
a) not too long lines
b) not C++ line comments
Zdar
Pavel
2010/12/11 t...@fuzzy.cz:
Hi everyone,
I just wrote my first patch, and I need to know whether I missed something
or not. I haven't used C for a really long time, so sickbags on standby,
Hello
you have to respect pg coding style:
a) not too long lines
b) not C++ line comments
OK, thanks for the notice. I've fixed those two problems.
regards
Tomasdiff --git a/src/backend/catalog/system_views.sql
b/src/backend/catalog/system_views.sql
index 346eaaf..0ee59b1 100644
---
On Sat, Dec 11, 2010 at 4:40 PM, t...@fuzzy.cz wrote:
Hello
you have to respect pg coding style:
a) not too long lines
b) not C++ line comments
OK, thanks for the notice. I've fixed those two problems.
Please add this to the currently-open commitfest.
27 matches
Mail list logo
