pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Ron <ronljohnsonjr@gmail.com>
To: pgsql-admin@lists.postgresql.org
Subject: Re: Diagnosing a massive toast file
Date: Mon, 5 Aug 2019 12:20:33 -0500
Message-ID: <a40fbfe5-6432-5696-fa34-e9225ec72a43@gmail.com> (raw)
In-Reply-To: <CAOC+FBXyYOE1+90qNDMJ_0W6F6pPxdKTEYP4HG2xHgT9KzbE=w@mail.gmail.com>
References: <CAOC+FBUPopsKh5wV5VC-CHCnVirtTghhwNwEtSD2ZaCZbXwOFg@mail.gmail.com>
	<3da6ffe8-28ef-fb9a-e6e8-1f0d243cc8e9@gmail.com>
	<CAOC+FBX1arTzF+_hx2WMsnOoF95gnnMZtNNkPUG+OKAERpisJg@mail.gmail.com>
	<6018.1565023741@sss.pgh.pa.us>
	<CAOC+FBWsvJJawBNBdan1n2pbQYWdZLvCF=2nUZq2hK0OHryXfg@mail.gmail.com>
	<CAOC+FBXyYOE1+90qNDMJ_0W6F6pPxdKTEYP4HG2xHgT9KzbE=w@mail.gmail.com>

"An open transaction" is the first place to look.

On 8/5/19 12:03 PM, Wells Oliver wrote:
> As a follow up, n_dead_tup from pg_stat_sys_tables for this TOAST table is 
> 7447444, live tuples, 623982, and tup_del 20823469. vacuum_count is 0.
>
> Why can't I free those rows up?
>
> On Mon, Aug 5, 2019 at 10:00 AM Wells Oliver <wells.oliver@gmail.com 
> <mailto:wells.oliver@gmail.com>> wrote:
>
>     Appreciate it, guys. I understand it being large isn't itself a
>     problem, but relative to history and the lack of real changes, it's
>     just strange and I'd like to better understand what is going on...
>
>     I tracked it down to a specific table, and then doing a VACUUM FULL
>     ANALYZE on that table yields: 108765 dead row versions cannot be
>     removed yet.
>
>     Which strikes me as odd. Any reading I can do to better understand why
>     so many (relative to the overall table size) dead rows cannot be removed?
>
>
>     On Mon, Aug 5, 2019 at 9:49 AM Tom Lane <tgl@sss.pgh.pa.us
>     <mailto:tgl@sss.pgh.pa.us>> wrote:
>
>         Wells Oliver <wells.oliver@gmail.com
>         <mailto:wells.oliver@gmail.com>> writes:
>         > Yeah, trying to figure out what actual table is clearly in need
>         of a vacuum
>         > b/c of the size of that toast table.
>
>         Something like
>
>         select relname from pg_class
>         where reltoastrelid = 'pg_toast.pg_toast_NNN'::regclass;
>
>         (or, if you have potential duplicate relnames, select
>         oid::regclass ...)
>
>         The mere fact that it's big does not indicate a problem, though.
>
>                                 regards, tom lane
>
>
>
>     -- 
>     Wells Oliver
>     wells.oliver@gmail.com <mailto:wellsoliver@gmail.com>
>
>
>
> -- 
> Wells Oliver
> wells.oliver@gmail.com <mailto:wellsoliver@gmail.com>

-- 
Angular momentum makes the world go 'round.

view thread (12+ messages)  latest in thread

Message-ID: <a40fbfe5-6432-5696-fa34-e9225ec72a43@gmail.com>
Permalink:  ../a40fbfe5-6432-5696-fa34-e9225ec72a43@gmail.com/
Also on:    postgresql.org/message-id/a40fbfe5-6432-5696-fa34-e9225ec72a43@gmail.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-admin@postgresql.org
  Cc: ronljohnsonjr@gmail.com, pgsql-admin@lists.postgresql.org
  Subject: Re: Diagnosing a massive toast file
  In-Reply-To: <a40fbfe5-6432-5696-fa34-e9225ec72a43@gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox