Re: [HACKERS] pg_stat_lwlock wait time view

I think the use-cases matter here to get a better design. I guess that's the reason why llya is looking for feature requests from DBA in another thread [3]. [3] https://www.postgresql.org/message-id/cag95seuaqvj09kzlwu%2bz1b-gqdmqerzekpfr3hn0q88xzmq...@mail.gmail.com Regards, -- Satoshi Nagayasu <sn...@uptime.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Wait events monitoring future development

2016/08/10 23:22 "Bruce Momjian" : > > On Wed, Aug 10, 2016 at 05:14:52PM +0300, Alexander Korotkov wrote: > > On Tue, Aug 9, 2016 at 5:37 AM, Bruce Momjian wrote: > > > > On Tue, Aug 9, 2016 at 02:06:40AM +, Tsunakawa, Takayuki wrote: > > > I hope

Re: [HACKERS] Wait events monitoring future development

Any thoughts? Seems a good starting point. I'm interested in both, and I would like to contribute with running (or writing) several tests. Regards, -- Satoshi Nagayasu <sn...@uptime.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Wait events monitoring future development

w I have another opinion. When we release the next major release saying 10.0 with the wait monitoring, many people will start their benchmark test with a configuration with *the default values*, and if they see some performance decrease, for example around 10%, they will be talking about it as the performance de

Re: [HACKERS] DROP OWNED BY ... CACADE & "could not open relation with OID" error

2016-07-21 13:53 GMT+09:00 Alvaro Herrera <alvhe...@2ndquadrant.com>: > Satoshi Nagayasu wrote: >> Hi, >> >> I have been trying MADlib [1], a machine-learning library for PostgreSQL, >> and when I was tying it on 9.5 and 9.6beta2, I often

[HACKERS] DROP OWNED BY ... CACADE & "could not open relation with OID" error

procedure? Regards, [1] http://madlib.incubator.apache.org/ -- Satoshi Nagayasu <sn...@uptime.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] PARALLEL SAFE/UNSAFE question

static/sql-createfunction.html -- Satoshi Nagayasu <sn...@uptime.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Actuall row count of Parallel Seq Scan in EXPLAIN ANALYZE .

-> Parallel Seq Scan on public.pgbench_accounts >> (cost=0.00..205601.67 rows=417 width=0) (actual time=0.042..1685.542 >> rows=1000 workers=2) >> Parent: actual time=0.033..1657.486 rows=2800963loops=1 >> Worker 0: actual time=0.033..1657.486 rows=3457968 >> loops=1 >> Worker 1: actual time=0.039..1702.979 rows=3741069 >> loops=1 How about this? Regards, -- Satoshi Nagayasu <sn...@uptime.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_stat_statements query jumbling question

On 2015/10/03 6:18, Peter Geoghegan wrote: On Wed, Sep 2, 2015 at 7:41 PM, Satoshi Nagayasu <sn...@uptime.jp> wrote: I know this still needs to be discussed, but I would like to submit a patch for further discussion at the next CF, 2015-11. I think I already expressed this in my expla

Re: [HACKERS] pg_stat_statements query jumbling question

On 2015/09/01 14:39, Satoshi Nagayasu wrote: > On 2015/09/01 14:01, Tom Lane wrote: >> Satoshi Nagayasu <sn...@uptime.jp> writes: >>> On 2015/09/01 13:41, Peter Geoghegan wrote: >>>> If you want to use the queryId field directly, which I recall you >&g

[HACKERS] pg_stat_statements query jumbling question

Hi, I have a question on jumbling queries in pg_stat_statements. I found that JumbleRangeTable() uses relation oid in RangeTblEntry. Obviously, this would result different queryid when the table gets re-created (dropped and created). Why don't we use relation name (with looking up the catalog)

Re: [HACKERS] pg_stat_statements query jumbling question

On 2015/09/01 13:41, Peter Geoghegan wrote: On Mon, Aug 31, 2015 at 9:29 PM, Satoshi Nagayasu <sn...@uptime.jp> wrote: BTW, I'm interested in improving the queryid portability now because I'd like to use it in other extensions. :) That's the reason why I'm looking at query jumblin

Re: [HACKERS] pg_stat_statements query jumbling question

On 2015/09/01 14:01, Tom Lane wrote: > Satoshi Nagayasu <sn...@uptime.jp> writes: >> On 2015/09/01 13:41, Peter Geoghegan wrote: >>> If you want to use the queryId field directly, which I recall you >>> mentioning before, then that's harder. There is simply

Re: [HACKERS] pg_stat_statements query jumbling question

On 2015/09/01 12:36, Peter Geoghegan wrote: On Mon, Aug 31, 2015 at 8:32 PM, Satoshi Nagayasu <sn...@uptime.jp> wrote: Why don't we use relation name (with looking up the catalog) on query jumbling? For performance reason? I think that there is a good case for preferring this be

Re: [HACKERS] Assert in pg_stat_statements

2015-08-10 0:04 GMT+09:00 Robert Haas robertmh...@gmail.com: On Sun, Aug 9, 2015 at 1:36 AM, Satoshi Nagayasu sn...@uptime.jp wrote: On 2015/08/08 22:32, Robert Haas wrote: On Sat, Aug 8, 2015 at 5:00 AM, Satoshi Nagayasu sn...@uptime.jp wrote: I just found that pg_stat_statements causes

Re: [HACKERS] Assert in pg_stat_statements

); I vote for this too. Jumble-calculation is the smartest way to identify query groups, so several modules can take advantages of it if in the core. Regards, -- Satoshi Nagayasu sn...@uptime.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

[HACKERS] Assert in pg_stat_statements

should not cause assert even if queryId already has non-zero value --- my module has this problem now. Is my understanding correct? Any comments? Regards, -- NAGAYASU Satoshi sn...@uptime.jp commit b975d7c2fe1b36a3ded1e0960be191466704e0fc Author: Satoshi Nagayasu sn...@uptime.jp Date: Sat Aug 8

[HACKERS] pg_filedump patch for 9.5

Hi, I have created a patch for pg_filedump to work with 9.5. Here is a list of changes. * Fix to rename CRC32 macros to work with 9.5. * Fix to add missing DBState: DB_SHUTDOWNED_IN_RECOVERY. * Fix to add missing page flags for Btree and GIN. * Update copyright date. Please take a look. Any

Re: [HACKERS] Assert in pg_stat_statements

On 2015/08/08 22:32, Robert Haas wrote: On Sat, Aug 8, 2015 at 5:00 AM, Satoshi Nagayasu sn...@uptime.jp wrote: I just found that pg_stat_statements causes assert when queryId is set by other module, which is loaded prior to pg_stat_statements in the shared_preload_libraries parameter

Re: [HACKERS] Fix to expose a GUC variable, Log_disconnections, to outside of postgres.c

On 2015/07/09 15:30, Heikki Linnakangas wrote: On 07/09/2015 07:19 AM, Satoshi Nagayasu wrote: On 2015/07/09 13:06, Tom Lane wrote: Satoshi Nagayasu sn...@uptime.jp writes: I just found that Log_disconnections value has not been exposed to outside of postgres.c. Despite

[HACKERS] Fix to expose a GUC variable, Log_disconnections, to outside of postgres.c

...@uptime.jp commit afffca193b69ea5eb42f5e7273d48a6a82eb7e37 Author: Satoshi Nagayasu sn...@uptime.jp Date: Thu Jul 9 03:42:31 2015 + Fix to expose Log_disconnections GUC variable to the outside postgres.c. diff --git a/src/include/postmaster/postmaster.h b/src/include/postmaster/postmaster.h

Re: [HACKERS] Fix to expose a GUC variable, Log_disconnections, to outside of postgres.c

On 2015/07/09 13:06, Tom Lane wrote: Satoshi Nagayasu sn...@uptime.jp writes: I just found that Log_disconnections value has not been exposed to outside of postgres.c. Despite that, Log_connections has already been exposed. Why would an external module need to touch either one? To check

Re: [HACKERS] pg_rewind in contrib

Hi, On 2014/12/12 23:13, Heikki Linnakangas wrote: Hi, I'd like to include pg_rewind in contrib. I originally wrote it as an external project so that I could quickly get it working with the existing versions, and because I didn't feel it was quite ready for production use yet. Now, with

Re: [HACKERS] pg_rewind in contrib

On 2014/12/16 18:37, Heikki Linnakangas wrote: On 12/16/2014 11:23 AM, Satoshi Nagayasu wrote: pg_rewind assumes that the source PostgreSQL has, at least, one checkpoint after getting promoted. I think the target timeline id in the pg_control file to be read is only available after the first

Re: [HACKERS] [PoC] pgstattuple2: block sampling to reduce physical read

(2013/10/11 7:32), Mark Kirkwood wrote: On 11/10/13 11:09, Mark Kirkwood wrote: On 16/09/13 16:20, Satoshi Nagayasu wrote: (2013/09/15 11:07), Peter Eisentraut wrote: On Sat, 2013-09-14 at 16:18 +0900, Satoshi Nagayasu wrote: I'm looking forward to seeing more feedback on this approach

Re: [HACKERS] [PATCH] Statistics collection for CLUSTER command

case here, not only for the view definition, but also working correctly. Please take a look at attached one. Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp diff --git a/src/test/regress/expected/stats.out b/src/test/regress/expected/stats.out index

Re: [HACKERS] Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist

not understood the pg_restore issue precisely so far, but IMHO DROP TRIGGER IF EXISTS means if the _trigger_ exists, not if the _table_ exists. Is this a correct and/or an expected behavior? Sorry if I missed some consensus which we already made. Any comments? Regards, -- Satoshi Nagayasu sn...@uptime.jp

Re: [HACKERS] [PoC] pgstattuple2: block sampling to reduce physical read

(2013/09/15 11:07), Peter Eisentraut wrote: On Sat, 2013-09-14 at 16:18 +0900, Satoshi Nagayasu wrote: I'm looking forward to seeing more feedback on this approach, in terms of design and performance improvement. So, I have submitted this for the next CF. Your patch fails to build

Re: [HACKERS] pg_system_identifier()

pg_catalog.pg_controldata; To get the system identifier value: select system_identifier from pg_catalog.pg_controldata; Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] [PoC] pgstattuple2: block sampling to reduce physical read

(2013/07/23 20:02), Greg Smith wrote: On 7/23/13 2:16 AM, Satoshi Nagayasu wrote: I've been working on new pgstattuple function to allow block sampling [1] in order to reduce block reads while scanning a table. A PoC patch is attached. Take a look at all of the messages linked in https

Re: [HACKERS] New statistics for WAL buffer dirty writes

Thanks for checking. Revised one attached. (2013/09/10 6:43), Peter Eisentraut wrote: On 9/6/13 11:32 PM, Satoshi Nagayasu wrote: The revised patch for wal buffer statistics is attached. A test script is also attached. Please take a look. You have duplicate OIDs. Run the script

Re: [HACKERS] New statistics for WAL buffer dirty writes

(2013/09/10 22:48), Peter Eisentraut wrote: On 9/10/13 3:37 AM, Satoshi Nagayasu wrote: Thanks for checking. Revised one attached. Please fix compiler warning: walwriter.c: In function ‘WalWriterMain’: walwriter.c:293:3: warning: implicit declaration of function ‘pgstat_send_walwriter

Re: [HACKERS] [rfc] overhauling pgstat.stat

(2013/09/09 8:19), Tomas Vondra wrote: On 8.9.2013 23:04, Jeff Janes wrote: On Tue, Sep 3, 2013 at 10:09 PM, Satoshi Nagayasu sn...@uptime.jp wrote: Hi, (2013/09/04 13:07), Alvaro Herrera wrote: Satoshi Nagayasu wrote: As you may know, this file could be handreds of MB in size, because

Re: [HACKERS] New statistics for WAL buffer dirty writes

Hi, The revised patch for wal buffer statistics is attached. A test script is also attached. Please take a look. Regards, (2013/07/19 7:49), Satoshi Nagayasu wrote: Will revise and re-resubmit for the next CF. Regards, 2013/07/19 1:06, Alvaro Herrera wrote: What happened to this patch

Re: [HACKERS] [rfc] overhauling pgstat.stat

(2013/09/04 15:23), Atri Sharma wrote: Sent from my iPad On 04-Sep-2013, at 10:54, Satoshi Nagayasu sn...@uptime.jp wrote: Hi, (2013/09/04 12:52), Atri Sharma wrote: On Wed, Sep 4, 2013 at 6:40 AM, Satoshi Nagayasu sn...@uptime.jp wrote: Hi, I'm considering overhauling pgstat.stat

Re: [HACKERS] [rfc] overhauling pgstat.stat

interested in this idea too. If the stat collector has a dedicated connection to the backend in order to store statistics into dedicated tables, we can easily take advantages of index (btree, or hash?) and heap storage. Is this worth trying? Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime

Re: [HACKERS] [rfc] overhauling pgstat.stat

storages, and it will allow us to minimize read/write operations. BTW, what kind of index would be preferred for this purpose? btree or hash? If we use btree, do we need range scan thing on the statistics tables? I have no idea so far. Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime

[HACKERS] [rfc] overhauling pgstat.stat

and btree in pgstat.stat would be preferred to reduce read/write and to allow updating access statistics for specific tables in pgstat.stat file. Is this good for us? Any comments or suggestions? Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp

Re: [HACKERS] [rfc] overhauling pgstat.stat

Hi, (2013/09/04 13:07), Alvaro Herrera wrote: Satoshi Nagayasu wrote: As you may know, this file could be handreds of MB in size, because pgstat.stat holds all access statistics in each database, and it needs to read/write an entire pgstat.stat frequently. As a result, pgstat.stat often

Re: [HACKERS] [rfc] overhauling pgstat.stat

Hi, (2013/09/04 12:52), Atri Sharma wrote: On Wed, Sep 4, 2013 at 6:40 AM, Satoshi Nagayasu sn...@uptime.jp wrote: Hi, I'm considering overhauling pgstat.stat, and would like to know how many people are interested in this topic. As you may know, this file could be handreds of MB in size

Re: [HACKERS] Compression of full-page-writes

the opinions about this idea before completing it, and then add the patch to next CF if okay. Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] Compression of full-page-writes

(2013/08/30 12:07), Satoshi Nagayasu wrote: (2013/08/30 11:55), Fujii Masao wrote: Hi, Attached patch adds new GUC parameter 'compress_backup_block'. When this parameter is enabled, the server just compresses FPW (full-page-writes) in WAL by using pglz_compress() before inserting

Re: [HACKERS] inconsistent state after crash recovery

detect and tell something about that, it would be really helpful for DBA to make some critical decision. I think PostgreSQL will be able to do that. Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp #!/bin/sh PGHOME=/tmp/pgsql PGDATA=/tmp/pgsql/data PATH

Re: [HACKERS] [9.4 CF 1]Commitfest ... over!

, and I'd like to hear if people think that helped. The 5-day rule (and the notifications from CFM) seemed to be working for me. It helped me focus on the patch review. Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp -- Sent via pgsql-hackers mailing list

[HACKERS] inconsistent state after crash recovery

. Any comments? Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp [snaga@devsv03 postgresql.git]$ sh test_recovery.sh createdb: database creation failed: ERROR: database testdb already exists drop table if exists t1; DROP TABLE create table t1 ( c1

[HACKERS] [PoC] pgstattuple2: block sampling to reduce physical read

operations might not have any skew over the table, so estimating table status seems to be easy in this test. However, I'm still curious to know whether it would work in real-world worklaod. Is it worth having this? Any comment or suggestion? Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime

Re: [HACKERS] New statistics for WAL buffer dirty writes

Will revise and re-resubmit for the next CF. Regards, 2013/07/19 1:06, Alvaro Herrera wrote: What happened to this patch? We were waiting on an updated version from you. Satoshi Nagayasu wrote: (2012/12/10 3:06), Tomas Vondra wrote: On 29.10.2012 04:58, Satoshi Nagayasu wrote: 2012/10

Re: [HACKERS] Fix pgstattuple/pgstatindex to use regclass-type as the argument

(2013/07/18 2:31), Fujii Masao wrote: On Tue, Jul 16, 2013 at 3:00 PM, Satoshi Nagayasu sn...@uptime.jp wrote: (2013/07/04 3:58), Fujii Masao wrote: For the test, I just implemented the regclass-version of pg_relpages() (patch attached) and tested some cases. But I could not get that problem

Re: [HACKERS] Fix pgstattuple/pgstatindex to use regclass-type as the argument

to be a good choice at this moment, in terms of backward-compatibility. Docs needs to be updated if this change going to be applied. Any comments? -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp diff --git a/contrib/pgstattuple/Makefile b/contrib/pgstattuple/Makefile

Re: [HACKERS] Fix pgstattuple/pgstatindex to use regclass-type as the argument

to handle the issue in three functions of the pgstattuple module. Please take a look. Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Add visibility map information to pg_freespace.

| 99.98 It seems working fine. And I added a regression test for pg_freespacemap and additional test cases for pgstattuple. Please take a look. Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp diff --git a/contrib/pg_freespacemap/Makefile b/contrib

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

- Please check attached script to reproduce it. Also, I have update the help message and README. Please check attached patch. Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp PGHOME=/tmp/pgsql PGPORT=15433 function

Re: [HACKERS] Block write statistics WIP

guess it need to have some fix, I couldn't clafiry it though. Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] Fix pgstattuple/pgstatindex to use regclass-type as the argument

(2013/06/17 4:02), Fujii Masao wrote: On Sat, Mar 9, 2013 at 3:23 PM, Satoshi Nagayasu sn...@uptime.jp wrote: It is obviously easy to keep two types of function interfaces, one with regclass-type and another with text-type, in the next release for backward-compatibility like below: pgstattuple

Re: [HACKERS] Add visibility map information to pg_freespace.

. - pgstattuple provies several functions for collecting specific table/index statistics. So, we can have similar feature in different modules. Any comments? Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] By now, why PostgreSQL 9.2 don't support SSDs?

block size, like 256kB, would take advantage of the SSD performance because of the block management within SSD. So, I'm just curious to know that. Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Fix pgstattuple/pgstatindex to use regclass-type as the argument

? Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Fix pgstattuple/pgstatindex to use regclass-type as the argument

('myschema.test_pkey'); select * from pgstatindex('myschema.test_pkey'::regclass::oid); With attached patch, all functions in the pgstattuple module can accept the same expression to specify the target relation/index. Any comments or suggestions? Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime

Re: [HACKERS] [RFC] pgstattuple/pgstatindex enhancement

(2013/02/15 1:55), Robert Haas wrote: On Tue, Feb 12, 2013 at 10:22 AM, Satoshi Nagayasu sn...@uptime.jp wrote: (1) Fix pgstatindex arguments to work same as pgstattuple. As the document describes, pgstattuple accepts 'schema.table' expression and oid of the table, but pgstatindex doesn't

[HACKERS] [RFC] pgstattuple/pgstatindex enhancement

/index is large (maybe 10GB or more). It would allow us to run pgstattuple/pgstatindex easier. Is it worth having? Any comments? Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] psql \l to accept patterns

support. It seems working well with the latest git master. I think it's good enough to be committed. BTW, is there any good place to put new regression test for the psql command? I couldn't find it out. Any comment or suggestion? Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies

Re: [HACKERS] psql \l to accept patterns

(2013/01/30 0:34), Tom Lane wrote: Satoshi Nagayasu sn...@uptime.jp writes: On Mon, 2013-01-07 at 07:14 -0500, Peter Eisentraut wrote: Here is a patch for psql's \l command to accept patterns, like \d BTW, is there any good place to put new regression test for the psql command? I couldn't

Re: [HACKERS] [PERFORM] pgbench to the MAXINT

the upper bound of int when sf21474.) Also, I added a few fixes on it. - Fixed to apply for the current git master. - Fixed to surpress few more warnings about INT64_FORMAT. - Minor improvement in the docs. (just my suggestion) I attached the revised one. Regards, -- Satoshi Nagayasu sn

Re: [HACKERS] buffer assertion tripping under repeat pgbench load

. Then, I need some suggestion from hackers to continue this review. How should I reproduce this message for review? This is a debug warning message, so it's not easy for me to reproduce this message. Any suggestion? -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC http

Re: [HACKERS] New statistics for WAL buffer dirty writes

(2012/11/27 7:42), Alvaro Herrera wrote: Satoshi Nagayasu escribió: I attached the latest one, which splits the reset_time for bgwriter and walwriter, and provides new system view, called pg_stat_walwriter, to show the dirty write counter and the reset time. Thanks. I gave this a look and I

Re: [HACKERS] New statistics for WAL buffer dirty writes

(2012/12/10 3:06), Tomas Vondra wrote: On 29.10.2012 04:58, Satoshi Nagayasu wrote: 2012/10/24 1:12, Alvaro Herrera wrote: Satoshi Nagayasu escribi�: With this patch, walwriter process and each backend process would sum up dirty writes, and send it to the stat collector. So, the value could

Re: [HACKERS] RFC: Timing Events

frequent queries. I think auto_explain would help you solve such rare incidents if it could dump several statistics into server log, including lock waits and block reads/writes statistic per-session, for example. Do we have something to add to auto_explain? Regards, -- Satoshi Nagayasu sn

Re: [HACKERS] New statistics for WAL buffer dirty writes

2012/10/24 1:12, Alvaro Herrera wrote: Satoshi Nagayasu escribió: With this patch, walwriter process and each backend process would sum up dirty writes, and send it to the stat collector. So, the value could be saved in the stat file, and could be kept on restarting. The statistics could

Re: [HACKERS] pg_stat_lwlocks view - lwlocks statistics, round 2

2012/10/19 4:36, Robert Haas wrote: On Tue, Oct 16, 2012 at 11:31 AM, Satoshi Nagayasu sn...@uptime.jp wrote: A flight-recorder must not be disabled. Collecting performance data must be top priority for DBA. This analogy is inapposite, though, because a flight recorder rarely crashes

Re: [HACKERS] pg_stat_lwlocks view - lwlocks statistics, round 2

2012/10/19 23:48, Fujii Masao wrote: On Wed, Oct 17, 2012 at 12:31 AM, Satoshi Nagayasu sn...@uptime.jp wrote: 2012/10/16 2:40, Jeff Janes wrote: On Sun, Oct 14, 2012 at 9:43 AM, Tom Lane t...@sss.pgh.pa.us wrote: Satoshi Nagayasu sn...@uptime.jp writes: (2012/10/14 13:26), Fujii Masao

Re: [HACKERS] pg_stat_lwlocks view - lwlocks statistics, round 2

2012/10/20 2:45, Tom Lane wrote: Satoshi Nagayasu sn...@uptime.jp writes: Ok, I guess we have reached the consensus to have some flight-recorder. Right? I remain unconvinced. I think the argument that this will promote novice understanding is complete hogwash: making any sense of lwlock

Re: [HACKERS] pg_stat_lwlocks view - lwlocks statistics, round 2

2012/10/16 2:40, Jeff Janes wrote: On Sun, Oct 14, 2012 at 9:43 AM, Tom Lane t...@sss.pgh.pa.us wrote: Satoshi Nagayasu sn...@uptime.jp writes: (2012/10/14 13:26), Fujii Masao wrote: The tracing lwlock usage seems to still cause a small performance overhead even if reporting is disabled. I

Re: [HACKERS] pg_stat_lwlocks view - lwlocks statistics, round 2

2012/10/15 1:43, Tom Lane wrote: Satoshi Nagayasu sn...@uptime.jp writes: (2012/10/14 13:26), Fujii Masao wrote: The tracing lwlock usage seems to still cause a small performance overhead even if reporting is disabled. I believe some users would prefer to avoid such overhead even

Re: [HACKERS] pg_stat_lwlocks view - lwlocks statistics, round 2

(2012/10/14 13:26), Fujii Masao wrote: On Sun, Oct 14, 2012 at 10:46 AM, Satoshi Nagayasu sn...@uptime.jp wrote: HEAD number of transactions actually processed: 3439971 tps = 57331.891602 (including connections establishing) tps = 57340.932324 (excluding connections establishing) snip

[HACKERS] pg_stat_lwlocks view - lwlocks statistics, round 2

. pg_stat_reset_lwlocks() New function to reset lwlock statistics. Please try it out. Regards, 2012/06/26 5:29, Satoshi Nagayasu wrote: Hi all, I've been working on a new system view, pg_stat_lwlocks, to observe LWLock, and just completed my 'proof-of-concept' code that can work

Re: [HACKERS] pg_stat_lwlocks view - lwlocks statistics, round 2

Hi, 2012/10/13 23:05, Satoshi Nagayasu wrote: Hi all, I have fixed my previous patch for pg_stat_lwlocks view, and as Josh commented, it now supports local and global (shared) statistics in the same system view. Sorry, I found my mistakes. New fixed one is attached to this mail. Regards

Re: [HACKERS] pg_stat_lwlocks view - lwlocks statistics, round 2

, Oct 13, 2012 at 11:34 PM, Satoshi Nagayasu sn...@uptime.jp mailto:sn...@uptime.jp wrote: Hi, 2012/10/13 23:05, Satoshi Nagayasu wrote: Hi all, I have fixed my previous patch for pg_stat_lwlocks view, and as Josh commented, it now supports local and global

Re: [HACKERS] New statistics for WAL buffer dirty writes

Hi, 2012/08/12 7:11, Jeff Janes wrote: On Sat, Jul 28, 2012 at 3:33 PM, Jeff Janes jeff.ja...@gmail.com wrote: On Sat, Jul 7, 2012 at 9:17 PM, Satoshi Nagayasu sn...@uptime.jp wrote: Hi, Jeff Janes has pointed out that my previous patch could hold a number of the dirty writes only in single

Re: [HACKERS] [PoC] load balancing in libpq

and again, it's time to consider implementing it to deliver and/or leverage with the potential of PostgreSQL replication. Regards, On 2012-09-23 10:01 AM, Euler Taveira eu...@timbira.com mailto:eu...@timbira.com wrote: On 23-09-2012 07:50, Satoshi Nagayasu wrote: I have just written

Re: [HACKERS] pg_reorg in core?

. AFAIK, basically, rebuilding tables and/or indexes has a trade-off between lock-free and disk-space. So, if we have enough disk space to build a temporary table/index when rebuilding a table/index, concurrently would be a great option, and I would love it to have in core. Regards, -- Satoshi

[HACKERS] [PoC] load balancing in libpq

]$ -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c index 9eaf410..14e31b6 100644 --- a/src/interfaces/libpq/fe-connect.c +++ b/src/interfaces/libpq/fe-connect.c @@ -569,6 +569,81

Re: [HACKERS] pg_reorg in core?

PGP SIGNATURE- -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_reorg in core?

development and enough eyeballs to maintain, it's ok to be an independent project. However when a tool have already got matured with less eyeballs, it needs to be merged into this umbrella project. Any comments? Sakamoto -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http

Re: [HACKERS] Adding probes for smgr

allocation strategy for some usages still seems like something we'll want to do someday, though. regards, tom lane -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

[HACKERS] Adding probes for smgr

? Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] XLogReader v2

, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] XLogReader v2

older major version could not take advantage of new features and enhancements of the latest xlogdump, but it's not what I wanted, actually. Regards, Greetings, Andres -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp -- Sent via pgsql-hackers mailing list

[HACKERS] New statistics for WAL buffer dirty writes

=# SELECT pg_stat_get_xlog_dirty_write(); pg_stat_get_xlog_dirty_write -- 0 (1 row) postgres=# \q [snaga@devvm03 src]$ --- -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http

Re: [HACKERS] New statistics for WAL buffer dirty writes

2012/07/07 22:07, Euler Taveira wrote: On 07-07-2012 09:00, Satoshi Nagayasu wrote: I've created new patch to get/reset statistics of WAL buffer writes (flushes) caused by WAL buffer full. This new statistic doesn't solve your problem (tune wal_buffers). It doesn't give you the wal_buffers

Re: [HACKERS] New statistics for WAL buffer dirty writes

into the shared memory, as a member of XLogCtlWrite, to keep total dirty writes in the cluster. Regards, 2012/07/07 21:00, Satoshi Nagayasu wrote: Hi all, I've created new patch to get/reset statistics of WAL buffer writes (flushes) caused by WAL buffer full. This patch provides two new functions

Re: [HACKERS] pg_stat_lwlocks view - lwlocks statistics

() New function to reset lwlock statistics. Please try it out. Regards, 2012/06/26 5:29, Satoshi Nagayasu wrote: Hi all, I've been working on a new system view, pg_stat_lwlocks, to observe LWLock, and just completed my 'proof-of-concept' code that can work with version 9.1. Now, I'd like

[HACKERS] pg_stat_lwlocks view - lwlocks statistics

. So, I want to show LWLock names (or labels), like 'WALWriteLock' or 'LockMgrLock', but how should I implement it? Any comments? Regards, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp diff -rc postgresql-9.1.2.orig/src/backend/catalog/postgres.bki

Re: [HACKERS] pg_stat_lwlocks view - lwlocks statistics

2012/06/26 6:44, Josh Berkus wrote: On 6/25/12 1:29 PM, Satoshi Nagayasu wrote: (1) Performance I've measured LWLock performance both with and without the patch, and confirmed that this patch does not affect the LWLock perfomance at all. This would be my main concern with this patch

Re: [HACKERS] pg_stat_lwlocks view - lwlocks statistics

2012/06/26 7:04, Kevin Grittner wrote: Josh Berkusj...@agliodbs.com wrote: On 6/25/12 1:29 PM, Satoshi Nagayasu wrote: (1) Performance I've measured LWLock performance both with and without the patch, and confirmed that this patch does not affect the LWLock perfomance at all

Re: [HACKERS] log messages for archive recovery progress

about this one? LOG: XXX file(s) from archive, YYY file(s) from pg_xlog successfully applied. Thanks, -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] log messages for archive recovery progress

2012/01/11 19:56, Simon Riggs wrote: 2012/1/11 Euler Taveira de Oliveiraeu...@timbira.com: On 08-01-2012 11:59, Satoshi Nagayasu / Uptime Technologies, LLC. wrote: [2011-12-08 15:14:36 JST] 16758: LOG: restored log file 00080046 from archive [2011-12-08 15:14:36 JST] 16758

[HACKERS] log messages for archive recovery progress

or directory [2011-12-08 15:14:37 JST] 16758: LOG: selected new timeline ID: 9 [2011-12-08 15:14:37 JST] 16758: LOG: restored log file 0008.history from archive [2011-12-08 15:14:38 JST] 16758: LOG: archive recovery complete Do you think this is useful? Thanks, -- Satoshi Nagayasu sn

Re: [HACKERS] LWLOCK_STATS

5 seconds. Screenshot here: http://twitpic.com/83p2cz Is this useful for pg developers? -- Satoshi Nagayasu sn...@uptime.jp Uptime Technologies, LLC. http://www.uptime.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

[HACKERS] xlogdump 0.4.0

Hi hackers, I'm pleased to announce the latest release of xlogdump. xlogdump is a tool for extracting data from WAL segment files. Here is xlogdump README: https://github.com/snaga/xlogdump/blob/master/xlogdump/README.xlogdump xlogdump was originally developed by Tom Lane and Diogo Biazus

Re: [HACKERS] top for postgresql (ptop?)

Mark, Very interesting. I'm looking for such tool. Unfortunately, I can't compile it on my Solaris right now, but I hope it will be shipped with PostgreSQL distribution. Mark Wong wrote: Hi everyone, I was playing with converting unixtop (the version of top used in FreeBSD) to only show

  1   2   >