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 bon
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
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
> accordin
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
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 results any longer.
> >
> > Versio
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
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 Output
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-
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 ro
Jean-David Beyer wrote:
[snip]
2007-11-14 12:00:31 EST DEBUG: analyzing "public.vl_in"
2007-11-14 12:00:31 EST DEBUG: "vl_in": scanned 2001 of 2001 pages,
containing 183983 live rows and 52 dead rows; 3000 rows in sample, 183983
estimated total rows
2007-11-14 12:00:31 EST DEBUG: analyzing "pu
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
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 pag
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 A
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 tra
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
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 A
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 e
Alvaro Herrera wrote:
> 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
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
20 matches
Mail list logo
