Skip site navigation (1) Skip section navigation (2)

Re: Curious about dead rows.

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Jean-David Beyer" <jeandavid8(at)verizon(dot)net>
Cc: "pgsql performance" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Curious about dead rows.
Date: 2007-11-14 03:36:11
Message-ID: b42b73150711131936l65b97b9ya7953383673b2710@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Nov 13, 2007 9:26 PM, Jean-David Beyer <jeandavid8(at)verizon(dot)net> 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 | n_tup_del
> ----------+----------+--------------+----------+---------------+-----------+-
>  ibd      |       75 |      9503850 |       11 |       2350555 |   2416845 |
>         0 |         0
>  vl_cf    |      139 |     38722575 |       22 |       5392609 |   5692814 |
>         0 |         0
>  vl_li    |      139 |     39992838 |       22 |       5569855 |   5885516 |
>         0 |         0
>
> I removed the relid and schemaname and squeezed the other columns so it
> would not be quite so wide. Is this what you might like to know?

it tells me that you aren't crazy, and that rollbacks are the likely
the cause, although you appear to be watching the logs pretty
carefully.  you can check pg_stat_database to confirm if your
rollbacks are in line with your expectations.  or, you might by seeing
some corner case conditions...are any fields in the table foreign
keyed to another table (cascading update/delete)?  do you have any
functions with handled exceptions or savepoints? (I'm guessing no to
the latter).

merlin

In response to

Responses

pgsql-performance by date

Next:From: Jean-David BeyerDate: 2007-11-14 12:12:45
Subject: Re: Curious about dead rows.
Previous:From: Merlin MoncureDate: 2007-11-14 03:20:41
Subject: Re: dell versus hp

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group