Jean-David Beyer wrote:
How do I reset the counters in pg_stat_database and pg_stat_all_tables?
I tried just restarting postgres, but it seems to be saved in the database,
not just in the RAM of the server.
There is a function called pg_stat_reset() or some such.
I suppose that blks_read
Merlin Moncure wrote:
On Nov 13, 2007 9:26 PM, Jean-David Beyer [EMAIL PROTECTED] wrote:
Merlin Moncure wrote:
what does pg_stat_all_tables say (assuming row level stats are on)?
It says stuff like this:
relname | seq_scan | seq_tup_read | idx_scan | idx_tup_fetch | n_tup_ins |
n_tup_upd
On Wed, Nov 14, 2007 at 07:12:45AM -0500, Jean-David Beyer wrote:
I know there have been rollbacks but I do a REINDEX, CLUSTER, and VACUUM
ANALYZE before starting the inserts in question. Do I need to do a VACUUM
FULL ANALYZE instead?
I had another idea. As Alvaro says, CLUSTER will do
Andrew Sullivan wrote:
On Wed, Nov 14, 2007 at 07:12:45AM -0500, Jean-David Beyer wrote:
I know there have been rollbacks but I do a REINDEX, CLUSTER, and
VACUUM ANALYZE before starting the inserts in question. Do I need to do
a VACUUM FULL ANALYZE instead?
I had another idea. As Alvaro
Andrew Sullivan wrote:
On Wed, Nov 14, 2007 at 07:12:45AM -0500, Jean-David Beyer wrote:
I know there have been rollbacks but I do a REINDEX, CLUSTER, and VACUUM
ANALYZE before starting the inserts in question. Do I need to do a VACUUM
FULL ANALYZE instead?
I had another idea. As Alvaro
On Wed, Nov 14, 2007 at 11:53:17AM -0500, Jean-David Beyer wrote:
that I run only one at a time, or leaving psql running. But as I understand
it, psql does not bother with transactions, and besides, I normally just do
No, every statement in psql is a transaction. Even SELECT. Every statement
On Wed, Nov 14, 2007 at 11:58:23AM -0500, Andrew Sullivan wrote:
No, every statement in psql is a transaction. Even SELECT. Every statement
Err, to be clearer, Every statement in psql is _somehow_ part of a
transaction; if you don't start one explicitly, the statement runs on its
own as a
Jean-David Beyer schrieb:
I am doing lots of INSERTs on a table that starts out empty (I did a
TRUNCATE on it). I am not, AFAIK, doing DELETEs or UPDATEs. Autovacuum is
on. I moved logging up to debug2 level to see what was going on, and I get
things like this:
vl_as: scanned 3000 of 5296
Jean-David Beyer wrote:
Mario Weilguni wrote:
Did you rollback some transactions? It will generate dead rows too - at
least I think so.
No, and the statistics confirm this.
To recap:
- your app only does inserts
- there has been no rollback lately
- there are no updates
- there are no
Alvaro Herrera wrote:
Jean-David Beyer wrote:
Mario Weilguni wrote:
Did you rollback some transactions? It will generate dead rows too - at
least I think so.
No, and the statistics confirm this.
To recap:
- your app only does inserts
True.
- there has been no rollback lately
On Wed, 14 Nov 2007, Alan Hodgson wrote:
On Tuesday 13 November 2007, Jeff Frost [EMAIL PROTECTED] wrote:
Ok, Areca ARC1261ML. Note that results were similar for an 8 drive RAID6
vs 8 drive RAID10, but I don't have those bonnie results any longer.
Version 1.03 --Sequential
On Tuesday 13 November 2007, Jeff Frost [EMAIL PROTECTED] wrote:
Ok, Areca ARC1261ML. Note that results were similar for an 8 drive RAID6
vs 8 drive RAID10, but I don't have those bonnie results any longer.
Version 1.03 --Sequential Output-- --Sequential Input-
--Random- -Per
Mario Weilguni wrote:
Jean-David Beyer schrieb:
I am doing lots of INSERTs on a table that starts out empty (I did a
TRUNCATE on it). I am not, AFAIK, doing DELETEs or UPDATEs. Autovacuum is
on. I moved logging up to debug2 level to see what was going on, and I
get
things like this:
Alvaro Herrera wrote:
To recap:
- your app only does inserts
- there has been no rollback lately
- there are no updates
- there are no deletes
The only other source of dead rows I can think is triggers ... do you
have any? (Not necessarily on this table -- perhaps triggers on other
tables can
Tom Lane wrote:
Russell Smith [EMAIL PROTECTED] writes:
It is possible that analyze is not getting the number of dead rows
right?
Hah, I think you are on to something. ANALYZE is telling the truth about
how many dead rows it saw, but its notion of dead is not good
according to
Russell Smith [EMAIL PROTECTED] writes:
It is possible that analyze is not getting the number of dead rows right?
Hah, I think you are on to something. ANALYZE is telling the truth
about how many dead rows it saw, but its notion of dead is not good
according to SnapshotNow. Thus, rows inserted
On Wed, 14 Nov 2007, Merlin Moncure wrote:
On Nov 14, 2007 5:24 PM, Alan Hodgson [EMAIL PROTECTED] wrote:
On Tuesday 13 November 2007, Jeff Frost [EMAIL PROTECTED] wrote:
Ok, Areca ARC1261ML. Note that results were similar for an 8 drive RAID6
vs 8 drive RAID10, but I don't have those bonnie
17 matches
Mail list logo
