Re: trying to use CLUSTER

From: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Sahagian, David *EXTERN*" <david(dot)sahagian(at)emc(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: trying to use CLUSTER
Date: 2013-02-13 10:43:40
Message-ID: A737B7A37273E048B164557ADEF4A58B057B2B29@ntex2010a.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

David Sahagian wrote:
> Version=9.1.7
>
> INFO: clustering "my_cool_table" using sequential scan and sort
> INFO: "my_cool_table": found 1 removable, 1699139 nonremovable row versions in 49762 pages
> Detail: 1689396 dead row versions cannot be removed yet.
> CPU 9.80s/4.98u sec elapsed 175.92 sec.

> My expectation is that a VERY SMALL percentage of the row versions would actually get written to the
> new table!

> Can somebody tell me why some "dead row versions cannot be removed yet" ?
>
> I assume that means CLUSTER must write them to the new table ?

I would say so. The dead rows probably cannot be removed because
of a long running transaction.

Is there a reason why you use CLUSTER and not VACUUM FULL?
Does VACUUM FULL show the same symptoms (dead row versions
cannot be removed yet)?

> Is there a way for me to discover the approx number of "non-removables" BEFORE I do the CLUSTER ?
> ? Some pg_table query ? maybe after an analyze ?

SELECT n_live_tup, n_dead_tup
FROM pg_stat_all_tables
WHERE relname = 'my_cool_table';

> Also, does the use of [index scan on "pk_cool"] basically depend on the ratio of
> removable/nonremovable row versions ?

I guess it will use whatever is cheaper (faster).

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alvaro Herrera 2013-02-13 13:02:47 Re: Re: permission denied to create extension "ltree" Must be superuser to create this extension.
Previous Message Albe Laurenz 2013-02-13 10:30:11 Re: PG V9 on NFS