Jeff Janes jeff.ja...@gmail.com wrote:
Alvaro Herrera alvhe...@2ndquadrant.com wrote:
So here's v11. I intend to commit this shortly. (I wanted to get it
out before lunch, but I introduced a silly bug that took me a bit to
fix.)
On Windows with Mingw I get this:
pgstat.c:4389:8:
Jeff Janes escribió:
On Mon, Feb 18, 2013 at 7:50 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
So here's v11. I intend to commit this shortly. (I wanted to get it
out before lunch, but I introduced a silly bug that took me a bit to
fix.)
On Windows with Mingw I get this:
Dne 19.02.2013 05:46, Alvaro Herrera napsal:
Alvaro Herrera wrote:
I have pushed it now. Further testing, of course, is always
welcome.
Mastodon failed:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mastodondt=2013-02-19%2000%3A00%3A01
probably worth investigating a bit; we might
Tomas Vondra t...@fuzzy.cz writes:
Dne 19.02.2013 05:46, Alvaro Herrera napsal:
Mastodon failed:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mastodondt=2013-02-19%2000%3A00%3A01
probably worth investigating a bit; we might have broken something.
Hmmm, interesting. A single
Dne 19.02.2013 11:27, Tom Lane napsal:
Tomas Vondra t...@fuzzy.cz writes:
Dne 19.02.2013 05:46, Alvaro Herrera napsal:
Mastodon failed:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mastodondt=2013-02-19%2000%3A00%3A01
probably worth investigating a bit; we might have broken
On 19.2.2013 11:27, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
Dne 19.02.2013 05:46, Alvaro Herrera napsal:
Mastodon failed:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mastodondt=2013-02-19%2000%3A00%3A01
probably worth investigating a bit; we might have broken something.
Tomas Vondra wrote:
AFAIK the stats remain the same within a transaction, and as a function
runs within a transaction, it will either get new data on the first
iteration, or it will run all 300 of them. I've checked several
buildfarm members and I'm yet to see a single duration between 12ms
On 19.2.2013 23:31, Alvaro Herrera wrote: Tomas Vondra wrote:
AFAIK the stats remain the same within a transaction, and as a
function runs within a transaction, it will either get new data on
the first iteration, or it will run all 300 of them. I've checked
several buildfarm members and I'm
On Mon, Feb 18, 2013 at 7:50 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
So here's v11. I intend to commit this shortly. (I wanted to get it
out before lunch, but I introduced a silly bug that took me a bit to
fix.)
On Windows with Mingw I get this:
pgstat.c:4389:8: warning:
Tomas Vondra wrote:
So, here's v10 of the patch (based on the v9+v9a), that implements the
approach described above.
It turned out to be much easier than I expected (basically just a
rewrite of the pgstat_read_db_statsfile_timestamp() function.
Thanks. I'm giving this another look now. I
On 18.2.2013 16:50, Alvaro Herrera wrote:
Tomas Vondra wrote:
So, here's v10 of the patch (based on the v9+v9a), that implements the
approach described above.
It turned out to be much easier than I expected (basically just a
rewrite of the pgstat_read_db_statsfile_timestamp() function.
Tomas Vondra wrote:
On 18.2.2013 16:50, Alvaro Herrera wrote:
Also, it seems to me that the new pgstat_db_requested() logic is
slightly bogus (in the inefficient sense, not the incorrect sense):
we should be comparing the timestamp of the request vs. what's already
on disk instead of
Alvaro Herrera wrote:
I have pushed it now. Further testing, of course, is always welcome.
Mastodon failed:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mastodondt=2013-02-19%2000%3A00%3A01
probably worth investigating a bit; we might have broken something.
--
Álvaro Herrera
On 17.2.2013 06:46, Alvaro Herrera wrote:
Tomas Vondra wrote:
I've been thinking about this (actually I had a really weird dream about
it this night) and I think it might work like this:
(1) check the timestamp of the global file - if it's too old, we need
to send an inquiry or wait a
On 15.2.2013 01:02, Tomas Vondra wrote:
On 14.2.2013 22:24, Alvaro Herrera wrote:
Alvaro Herrera escribió:
Here's a ninth version of this patch. (version 8 went unpublished). I
have simplified a lot of things and improved some comments; I think I
understand much of it now. I think this
Tomas Vondra wrote:
I've been thinking about this (actually I had a really weird dream about
it this night) and I think it might work like this:
(1) check the timestamp of the global file - if it's too old, we need
to send an inquiry or wait a bit longer
(2) if it's new enough, we
Tomas Vondra escribió:
On 14.2.2013 20:23, Alvaro Herrera wrote:
The problem here is that creating these dummy entries will cause a
difference in autovacuum behavior. Autovacuum will skip processing
databases with no pgstat entry, and the intended reason is that if
there's no pgstat
On 15.2.2013 16:38, Alvaro Herrera wrote:
Tomas Vondra escribió:
On 14.2.2013 20:23, Alvaro Herrera wrote:
The problem here is that creating these dummy entries will cause a
difference in autovacuum behavior. Autovacuum will skip processing
databases with no pgstat entry, and the
Alvaro Herrera escribió:
Hm, and I now also realize another bug in this patch: the global stats
only include database entries for requested databases; but perhaps the
existing files can serve later requestors just fine for databases that
already had files; so the global stats file should
Here's a ninth version of this patch. (version 8 went unpublished). I
have simplified a lot of things and improved some comments; I think I
understand much of it now. I think this patch is fairly close to
committable, but one issue remains, which is this bit in
pgstat_write_statsfiles():
I saw discussion about this on this thread, but I'm not able to figure
out what the answer is: how does this work with moving the stats file,
for example to a RAMdisk? Specifically, if the user sets
stats_temp_directory, does it continue to work the way it does now?
--
Josh Berkus
PostgreSQL
Josh Berkus wrote:
I saw discussion about this on this thread, but I'm not able to figure
out what the answer is: how does this work with moving the stats file,
for example to a RAMdisk? Specifically, if the user sets
stats_temp_directory, does it continue to work the way it does now?
Of
Alvaro Herrera escribió:
Here's a ninth version of this patch. (version 8 went unpublished). I
have simplified a lot of things and improved some comments; I think I
understand much of it now. I think this patch is fairly close to
committable, but one issue remains, which is this bit in
Alvaro Herrera escribió:
Here's a ninth version of this patch. (version 8 went unpublished). I
have simplified a lot of things and improved some comments; I think I
understand much of it now. I think this patch is fairly close to
committable, but one issue remains, which is this bit in
On 14.2.2013 20:43, Josh Berkus wrote:
I saw discussion about this on this thread, but I'm not able to figure
out what the answer is: how does this work with moving the stats file,
for example to a RAMdisk? Specifically, if the user sets
stats_temp_directory, does it continue to work the way
First of all, big thanks for working on this patch and not only
identifying the issues but actually fixing them.
On 14.2.2013 20:23, Alvaro Herrera wrote:
Here's a ninth version of this patch. (version 8 went unpublished). I
have simplified a lot of things and improved some comments; I think
On 14.2.2013 22:24, Alvaro Herrera wrote:
Alvaro Herrera escribió:
Here's a ninth version of this patch. (version 8 went unpublished). I
have simplified a lot of things and improved some comments; I think I
understand much of it now. I think this patch is fairly close to
committable, but
Tomas Vondra escribió:
I don't see how that changes the autovacuum behavior. Can you explain
that a bit more?
It might be that I'm all wet on this. I'll poke at it some more.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training
Here's an updated version of this patch that takes care of the issues I
reported previously: no more repalloc() of the requests array; it's now
an slist, which makes the code much more natural IMV. And no more
messing around with doing sprintf to create a separate sprintf pattern
for the per-db
On Tue, Feb 5, 2013 at 2:31 PM, Tomas Vondra t...@fuzzy.cz wrote:
We do not already have this. There is no relevant spec. I can't see
how this could need pg_dump support (but what about pg_upgrade?)
pg_dump - no
pg_upgrage - IMHO it should create the pg_stat directory. I don't think
it
Pavel Stehule pavel.steh...@gmail.com writes:
Nice. Another interesting numbers would be device utilization, average
I/O speed and required space (which should be ~2x the pgstat.stat size
without the patch).
this point is important - with large warehouse with lot of databases
and tables you
Tom Lane escribió:
Pavel Stehule pavel.steh...@gmail.com writes:
Nice. Another interesting numbers would be device utilization, average
I/O speed and required space (which should be ~2x the pgstat.stat size
without the patch).
this point is important - with large warehouse with lot of
2013/2/6 Alvaro Herrera alvhe...@2ndquadrant.com:
Tom Lane escribió:
Pavel Stehule pavel.steh...@gmail.com writes:
Nice. Another interesting numbers would be device utilization, average
I/O speed and required space (which should be ~2x the pgstat.stat size
without the patch).
this point
Dne 06.02.2013 16:53, Alvaro Herrera napsal:
Tom Lane escribió:
Pavel Stehule pavel.steh...@gmail.com writes:
Nice. Another interesting numbers would be device utilization,
average
I/O speed and required space (which should be ~2x the pgstat.stat
size
without the patch).
this point is
On Tue, Feb 5, 2013 at 2:31 PM, Tomas Vondra t...@fuzzy.cz wrote:
On 5.2.2013 19:23, Jeff Janes wrote:
If I shutdown the server and blow away the stats with rm
data/pg_stat/*, it recovers gracefully when I start it back up. If a
do rm -r data/pg_stat then it has problems the next time I shut
Jeff Janes jeff.ja...@gmail.com writes:
On Tue, Feb 5, 2013 at 2:31 PM, Tomas Vondra t...@fuzzy.cz wrote:
U, what you mean by catalog bump?
There is a catalog number in src/include/catalog/catversion.h, which
when changed forces one to redo initdb.
Formally I guess it is only for system
On 7.2.2013 00:40, Tom Lane wrote:
Jeff Janes jeff.ja...@gmail.com writes:
On Tue, Feb 5, 2013 at 2:31 PM, Tomas Vondra t...@fuzzy.cz wrote:
U, what you mean by catalog bump?
There is a catalog number in src/include/catalog/catversion.h, which
when changed forces one to redo initdb.
On Sun, Feb 3, 2013 at 4:51 PM, Tomas Vondra t...@fuzzy.cz wrote:
LOG: last_statwrite 11133-08-28 19:22:31.711744+02 is later than
collector's time 2013-02-04 00:54:21.113439+01 for db 19093
WARNING: pgstat wait timeout
LOG: last_statwrite 39681-12-23 18:48:48.9093+01 is later than
On 5.2.2013 19:23, Jeff Janes wrote:
On Sun, Feb 3, 2013 at 4:51 PM, Tomas Vondra t...@fuzzy.cz wrote:
LOG: last_statwrite 11133-08-28 19:22:31.711744+02 is later than
collector's time 2013-02-04 00:54:21.113439+01 for db 19093
WARNING: pgstat wait timeout
LOG: last_statwrite 39681-12-23
with the patch:
vacuumdb -areal6m41.306s
idle steady state: 7.86% user, 5.00% system 0.09% iowait 87% idle,
Nice. Another interesting numbers would be device utilization, average
I/O speed and required space (which should be ~2x the pgstat.stat size
without the patch).
this
On Sat, Jan 5, 2013 at 8:03 PM, Tomas Vondra t...@fuzzy.cz wrote:
On 3.1.2013 20:33, Magnus Hagander wrote:
Yeah, +1 for a separate directory not in global.
OK, I moved the files from global/stat to stat.
Why stat rather than pg_stat?
The existence of global and base as exceptions already
On Sat, Feb 2, 2013 at 2:33 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Sat, Jan 5, 2013 at 8:03 PM, Tomas Vondra t...@fuzzy.cz wrote:
On 3.1.2013 20:33, Magnus Hagander wrote:
Yeah, +1 for a separate directory not in global.
OK, I moved the files from global/stat to stat.
This has a
On 3.2.2013 20:46, Jeff Janes wrote:
On Sat, Jan 5, 2013 at 8:03 PM, Tomas Vondra t...@fuzzy.cz wrote:
On 3.1.2013 20:33, Magnus Hagander wrote:
Yeah, +1 for a separate directory not in global.
OK, I moved the files from global/stat to stat.
Why stat rather than pg_stat?
The existence
On 2.2.2013 23:33, Jeff Janes wrote:
On Sat, Jan 5, 2013 at 8:03 PM, Tomas Vondra t...@fuzzy.cz wrote:
On 3.1.2013 20:33, Magnus Hagander wrote:
Yeah, +1 for a separate directory not in global.
OK, I moved the files from global/stat to stat.
This has a warning:
pgstat.c:5132: warning:
On 3.2.2013 21:54, Jeff Janes wrote:
On Sat, Feb 2, 2013 at 2:33 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Sat, Jan 5, 2013 at 8:03 PM, Tomas Vondra t...@fuzzy.cz wrote:
On 3.1.2013 20:33, Magnus Hagander wrote:
Yeah, +1 for a separate directory not in global.
OK, I moved the files from
On 1.2.2013 17:19, Alvaro Herrera wrote:
Tomas Vondra wrote:
diff --git a/src/backend/postmaster/pgstat.c
b/src/backend/postmaster/pgstat.c
index be3adf1..4ec485e 100644
--- a/src/backend/postmaster/pgstat.c
+++ b/src/backend/postmaster/pgstat.c
@@ -64,10 +64,14 @@
/* --
On Sat, Jan 5, 2013 at 8:03 PM, Tomas Vondra t...@fuzzy.cz wrote:
On 3.1.2013 20:33, Magnus Hagander wrote:
Yeah, +1 for a separate directory not in global.
OK, I moved the files from global/stat to stat.
This has a warning:
pgstat.c:5132: warning: 'pgstat_write_statsfile_needed' was used
: pgsql-hackers@postgresql.org
Předmět: Re: PATCH: Split stats file per database WAS: [HACKERS] autovacuum
stress-testing our system
On Sat, Jan 5, 2013 at 8:03 PM, Tomas Vondra t...@fuzzy.cz wrote:
On 3.1.2013 20:33, Magnus Hagander wrote:
Yeah, +1 for a separate directory not in global.
OK, I
Tomas Vondra wrote:
diff --git a/src/backend/postmaster/pgstat.c b/src/backend/postmaster/pgstat.c
index be3adf1..4ec485e 100644
--- a/src/backend/postmaster/pgstat.c
+++ b/src/backend/postmaster/pgstat.c
@@ -64,10 +64,14 @@
/* --
* Paths for the statistics files (relative to
On 3.1.2013 20:33, Magnus Hagander wrote:
On Thu, Jan 3, 2013 at 8:31 PM, Tomas Vondra t...@fuzzy.cz wrote:
On 3.1.2013 18:47, Heikki Linnakangas wrote:
How about creating the new directory as a direct subdir of $PGDATA,
rather than buried in global? global is supposed to contain data
related
On 03.01.2013 01:15, Tomas Vondra wrote:
2) a new global/stat directory
--
The pgstat.stat file was originally saved into the global directory,
but with so many files that would get rather messy so I've created a new
global/stat directory and all the files are stored
On 3.1.2013 18:47, Heikki Linnakangas wrote:
On 03.01.2013 01:15, Tomas Vondra wrote:
2) a new global/stat directory
--
The pgstat.stat file was originally saved into the global directory,
but with so many files that would get rather messy so I've created a new
On Thu, Jan 3, 2013 at 8:31 PM, Tomas Vondra t...@fuzzy.cz wrote:
On 3.1.2013 18:47, Heikki Linnakangas wrote:
On 03.01.2013 01:15, Tomas Vondra wrote:
2) a new global/stat directory
--
The pgstat.stat file was originally saved into the global directory,
but with
53 matches
Mail list logo
