Re: Reduce maximum error in tuples estimation after vacuum.

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: Reduce maximum error in tuples estimation after vacuum.
Дата
Msg-id 20130625.173618.91523933.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Reduce maximum error in tuples estimation after vacuum.  (Amit Kapila <amit.kapila@huawei.com>)
Ответы Re: Reduce maximum error in tuples estimation after vacuum.  (Amit Kapila <amit.kapila@huawei.com>)
Список pgsql-hackers
Hello, 

> I have tried to reproduce the problem in different m/c's, but couldn't
> reproduce it.
> I have ran tests with default configuration.

I think you had reproduced it.

> Output on Windows:
> -------------------
> postgres=# create table t (a int, b int); 
(snip)
> postgres=# select n_live_tup, n_dead_tup from pg_stat_user_tables where
> relname= 
> 't'; 
>  n_live_tup | n_dead_tup 
> ------------+------------ 
>       10001 |     989999 
> (1 row)

Yes, this is the same for me. You should've done this instead,

postgres=# select reltuples from pg_class where relname = 't';reltuples 
-----------    1e+06
(1 row)

This is 100 times larger than n_live_tup, and it is this value
which used for judge the necessity of autovacuum.

autovacuum.c: 2695
|   reltuples = classForm->reltuples;
|   vactuples = tabentry->n_dead_tuples;
....   
|   vacthresh = (float4) vac_base_thresh + vac_scale_factor * reltuples;
|   anlthresh = (float4) anl_base_thresh + anl_scale_factor * reltuples;

Although..

> Output on Suse
> ----------------
> postgres=# drop table if exists t; 
> create table t (a int, b int); 
> insert into t (select a, (random() * 100000)::int from
> generate_series((select count(*) from t) + 1, 1000000) a); 
> update t set b = b + 1 where a <  (select count(*) from t) * 0.7; 
> vacuum t; 
> delete from t where a < (select count(*) from t) * 0.99; 
> vacuum t; 
> select c.relpages, s.n_live_tup, c.reltuples, (select count(*) from t) as
> tuples, reltuples::float / (select count(*) from t) as ratio  from
> pg_stat_user_tables s, pg_class c where s.relname = 't' and c.relname =
> 't';DROP TABLE 
> postgres=# CREATE TABLE 
> postgres=# INSERT 0 1000000 
> postgres=# UPDATE 699999 
> postgres=# VACUUM 
> postgres=# DELETE 989999 
> postgres=# VACUUM 
> postgres=# 
>  relpages | n_live_tup | reltuples | tuples | ratio 
> ----------+------------+-----------+--------+------- 
>      4425 |      10001 |     10001 |  10001 |     1 
> (1 row)

... Mmm.. I have following figures for the same operation.

relpages | n_live_tup | reltuples | tuples |      ratio       
----------+------------+-----------+--------+------------------    4425 |     417670 |    417670 |  10001 |
41.7628237176282

I condisider on this for a time..

> When I tried to run vactest.sh, it gives below error:
> linux:~/akapila/vacuum_nlivetup> ./vactest.sh 
> ./vactest.sh: line 11: syntax error near unexpected token `&' 
> ./vactest.sh: line 11: `        psql ${dbname} -c "vacuum verbose t" |&
> egrep "INFO: *\"t\": found " | sed -e 's/^.* versions in \([0-9]*\)
> .*$/\1/''
> 
> 
> Can you help me in reproducing the problem by letting me know if I am doing
> something wrong or results of test are not predictable?

Could you let me know the pg's version you're running?  And it is
appreciated if you're kindly show me the vacuum logs while
testing.

# I found a silly bug in the patch, but I put it off.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Misa Simic
Дата:
Сообщение: PostgreSQL 9.3 latest dev snapshot
Следующее
От: Jeevan Chalke
Дата:
Сообщение: Re: [Review] Add SPI_gettypmod() to return a field's typemod from a TupleDesc