...@postgresql.org] On Behalf Of Naoya Anzai
Sent: Tuesday, June 16, 2015 8:41 AM
To: Tomas Vondra
Cc: pgsql-hackers@postgresql.org; Akio Iwaasa; bench.cof...@gmail.com; Tom
Lane; Jeff Janes; Jim Nasby; Andres Freund; Alvaro Herrera
Subject: Re: [HACKERS] [Proposal] More Vacuum Statistics
Hi,
Thank you
Hi,
Thank you for comments. and Sorry for my late response.
pg_stat_vacuum view
I understand it is not good to simply add more counters in
pg_stat_*_tables. For now, I'd like to suggest an extension
which can confirm vacuum statistics like
Hi,
On 06/05/15 14:10, Naoya Anzai wrote:
Thank you for quick feedback, and I'm sorry for slow response.
All of your opinions were very helpful for me.
I have confirmed Greg's Idea Timing events.
http://www.postgresql.org/message-id/509300f7.5000...@2ndquadrant.com
Greg said at first,
Parsing
Thank you for quick feedback, and I'm sorry for slow response.
All of your opinions were very helpful for me.
I have confirmed Greg's Idea Timing events.
http://www.postgresql.org/message-id/509300f7.5000...@2ndquadrant.com
Greg said at first,
Parsing log files for commonly needed performance
Hi,
On 05/30/15 04:41, Andres Freund wrote:
On 2015-05-29 21:30:57 -0500, Jim Nasby wrote:
It occurs to me that there's no good reason for vacuum-derived stats to be
in the stats file; it's not like users run vacuum anywhere near as often as
other commands. It's stats could be kept in
On 05/30/15 16:47, Tom Lane wrote:
Another reason why that would be a bad place is that a pg_class update
forces relcache invalidation and thereby cached-plan invalidation.
You don't want that for anything except (1) DDL affecting the table or
(2) change in statistics that affect plan
Andres Freund and...@anarazel.de writes:
On 2015-05-29 21:30:57 -0500, Jim Nasby wrote:
It occurs to me that there's no good reason for vacuum-derived stats to be
in the stats file; it's not like users run vacuum anywhere near as often as
other commands. It's stats could be kept in pg_class;
On Thu, May 28, 2015 at 4:08 AM, Naoya Anzai nao-an...@xc.jp.nec.com
wrote:
2. Page visibility rate of each table
There is no way to know how many page-bits are them of each tables stored
in their visibility maps. If we can show this information, then we will be
able to guess vacuum overhead
On 5/28/15 9:14 AM, Tom Lane wrote:
Naoya Anzai nao-an...@xc.jp.nec.com writes:
In my much experience up until now,I have an idea that we can add
2 new vacuum statistics into pg_stat_xxx_tables.
Adding new stats in that way requires adding per-table counters, which
bloat the statistics files
On 2015-05-29 21:30:57 -0500, Jim Nasby wrote:
It occurs to me that there's no good reason for vacuum-derived stats to be
in the stats file; it's not like users run vacuum anywhere near as often as
other commands. It's stats could be kept in pg_class; we're already keeping
things like
Andres Freund wrote:
On 2015-05-29 21:30:57 -0500, Jim Nasby wrote:
It occurs to me that there's no good reason for vacuum-derived stats to be
in the stats file; it's not like users run vacuum anywhere near as often as
other commands. It's stats could be kept in pg_class; we're already
Naoya Anzai nao-an...@xc.jp.nec.com writes:
In my much experience up until now,I have an idea that we can add
2 new vacuum statistics into pg_stat_xxx_tables.
Adding new stats in that way requires adding per-table counters, which
bloat the statistics files (especially in database with very
12 matches
Mail list logo
