Re: pgsql 10: hash indexes testing

On Wed, Jul 05, 2017 at 03:33:45PM +1000, AP wrote:
> > Do you have any deletes?  How have you verified whether autovacuum has
> 
> No DELETEs. Just the initial COPY, then SELECTs, then a DB rename to get it
> out of the way of other testing, then the REINDEX.
> 
> > been triggered or not?
> 
> I just checked pg_stat_user_tables (which I hope is the right place for
> this info :)
> 
>    relid   | schemaname | relname | seq_scan | seq_tup_read | idx_scan | idx_tup_fetch | n_tup_ins  | n_tup_upd | n_tup_del | n_tup_hot_upd | n_live_tup | n_dead_tup | n_mod_since_analyze | last_vacuum | last_autovacuum |         last_analyze          |       last_autoanalyze        | vacuum_count | autovacuum_count | analyze_count | autoanalyze_count
> -----------+------------+---------+----------+--------------+----------+---------------+------------+-----------+-----------+---------------+------------+------------+---------------------+-------------+-----------------+-------------------------------+-------------------------------+--------------+------------------+---------------+-------------------
>  129311803 | public     | link    |       70 |  15085880072 |     5779 |        465623 | 2975444240 |         0 |         0 |             0 |  928658178 |          0 |                   0 |             |                 |                               | 2017-06-28 10:43:51.273241+10 |            0 |                0 |             0 |                 2
> 
> So it appears not.

Actually, after a bit more late-arvo thought, I take it this would be the
case as the table has not changed since creation. Thus no need to autovac.

I've newer timestamps on the live db (whose data was uploaded more recently)
for its tables so I think autovac is functioning.

AP