When I run this query



fwdb01=# select current_timestamp,datname,age(datfrozenxid) from
pg_database;

now | datname | age

-------------------------------+-----------+------------

2006-09-28 18:04:24.489935+00 | postgres | 1087834006

2006-09-28 18:04:24.489935+00 | fwdb01 | 2039254861

2006-09-28 18:04:24.489935+00 | template1 | 2039253122

2006-09-28 18:04:24.489935+00 | template0 | 1542808250

(4 rows)



fwdb01=# select current_timestamp,datname,age(datfrozenxid) from
pg_database;

now | datname | age

------------------------------+-----------+------------

2006-09-28 18:10:45.64452+00 | postgres | 1088357075

2006-09-28 18:10:45.64452+00 | fwdb01 | 2039777930

2006-09-28 18:10:45.64452+00 | template1 | 2039776191

2006-09-28 18:10:45.64452+00 | template0 | 1543331319





In approximately 6 minutes, the fwdb01 count has gone up by about 500K.
I am generating about 250K rows for every 6 . I am also running
vacuumdb.



Does vacuumdb generate a lot of transactions that affects this counter.

Hi sriram,

datfrozenxid column of pg_database row is updated at the completion of any
database wide vacuum operation. The value store here is the cuttoff xid used
by the vacuum operation all xid's older then this cutoffxid are replaced by
theis xid so i think the behaviour being shown by your database is quite
normal.

Regards
Talha Khan

The datfrozenxid column of a database's pg_database row is updated at the
completion of any database-wide VACUUM operation (i.e., VACUUM that does not
name a specific table). The value stored in this field is the freeze cutoff
XID that was used by that VACUUM command. All normal XIDs older than this
cutoff XID are guaranteed to have been replaced by FrozenXID within that
database


On 9/28/06, Sriram Dandapani <sdandapani@counterpane.com> wrote:
>
> When I run this query
>
>
>
> fwdb01=# select current_timestamp,datname,age(datfrozenxid) from
> pg_database;
>
> now | datname | age
>
> -------------------------------+-----------+------------
>
> 2006-09-28 18:04:24.489935+00 | postgres | 1087834006
>
> 2006-09-28 18:04:24.489935+00 | fwdb01 | 2039254861
>
> 2006-09-28 18:04:24.489935+00 | template1 | 2039253122
>
> 2006-09-28 18:04:24.489935+00 | template0 | 1542808250
>
> (4 rows)
>
>
>
> fwdb01=# select current_timestamp,datname,age(datfrozenxid) from
> pg_database;
>
> now | datname | age
>
> ------------------------------+-----------+------------
>
> 2006-09-28 18:10:45.64452+00 | postgres | 1088357075
>
> 2006-09-28 18:10:45.64452+00 | fwdb01 | 2039777930
>
> 2006-09-28 18:10:45.64452+00 | template1 | 2039776191
>
> 2006-09-28 18:10:45.64452+00 | template0 | 1543331319
>
>
>
>
>
> In approximately 6 minutes, the fwdb01 count has gone up by about 500K. I
> am generating about 250K rows for every 6 . I am also running vacuumdb.
>
>
>
> Does vacuumdb generate a lot of transactions that affects this counter.
>

Interesting... age(xid) isn't documented anywhere.

No, vacuum shouldn't be generating a lot of xid's. My guess is that your
generating process actually does 2 transactions per row.

On Thu, Sep 28, 2006 at 11:16:24AM -0700, Sriram Dandapani wrote:
> When I run this query
>
>
>
> fwdb01=# select current_timestamp,datname,age(datfrozenxid) from
> pg_database;
>
> now | datname | age
>
> -------------------------------+-----------+------------
>
> 2006-09-28 18:04:24.489935+00 | postgres | 1087834006
>
> 2006-09-28 18:04:24.489935+00 | fwdb01 | 2039254861
>
> 2006-09-28 18:04:24.489935+00 | template1 | 2039253122
>
> 2006-09-28 18:04:24.489935+00 | template0 | 1542808250
>
> (4 rows)
>
>
>
> fwdb01=# select current_timestamp,datname,age(datfrozenxid) from
> pg_database;
>
> now | datname | age
>
> ------------------------------+-----------+------------
>
> 2006-09-28 18:10:45.64452+00 | postgres | 1088357075
>
> 2006-09-28 18:10:45.64452+00 | fwdb01 | 2039777930
>
> 2006-09-28 18:10:45.64452+00 | template1 | 2039776191
>
> 2006-09-28 18:10:45.64452+00 | template0 | 1543331319
>
>
>
>
>
> In approximately 6 minutes, the fwdb01 count has gone up by about 500K.
> I am generating about 250K rows for every 6 . I am also running
> vacuumdb.
>
>
>
> Does vacuumdb generate a lot of transactions that affects this counter.
>

--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Thu, Sep 28, 2006 at 11:58:12AM -0700, Talha Khan wrote:
> datfrozenxid column of pg_database row is updated at the completion of any
> database wide vacuum operation. The value store here is the cuttoff xid used
> by the vacuum operation all xid's older then this cutoffxid are replaced by
> theis xid so i think the behaviour being shown by your database is quite
> normal.

True, but if age(xid) is showing how many transactions have occured
since xid then his conclusion that he did 500k transactions between
those two snapshots is correct.
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings