thank you all for your help. finally the big table had many more rows(2
billions) than the stats showed so there is no "weird" thing going on.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/weird-table-sizes-tp4626505p4630238.html
Sent from the PostgreSQL - general mail
On Sun, Jul 24, 2011 at 11:45 AM, Adrian Klaver wrote:
> On Saturday, July 23, 2011 3:34:07 pm MirrorX wrote:
>> i mentioned the sequences number only b/c it seemed stange and i didnt know
>> if it could be related to the "weird" sizes.
>>
>> now i found something more weird...the autovacuum is ON
On Saturday, July 23, 2011 3:34:07 pm MirrorX wrote:
> i mentioned the sequences number only b/c it seemed stange and i didnt know
> if it could be related to the "weird" sizes.
>
> now i found something more weird...the autovacuum is ON but on
> pg_stat_user_tables on this specific table tha last
i mentioned the sequences number only b/c it seemed stange and i didnt know
if it could be related to the "weird" sizes.
now i found something more weird...the autovacuum is ON but on
pg_stat_user_tables on this specific table tha last_vacuum and
last_autovacuum are both NULL...how can this happen
On Saturday, July 23, 2011 12:18:25 pm MirrorX wrote:
> thx for the reply :)
>
> the table are identical, and i mean that they have the same columns, the
> same constraints, the same indexes etc
>
> 1) the small table(65gb) is on version 8.4.7 and the big one(430gb) on
> 8.4.4 2) the small in on
thx for the reply :)
the table are identical, and i mean that they have the same columns, the
same constraints, the same indexes etc
1) the small table(65gb) is on version 8.4.7 and the big one(430gb) on 8.4.4
2) the small in on Red Hat 4.1.2-50 and the big on Red Hat 4.1.2-46
3) the 2nd was rest
On Saturday, July 23, 2011 11:29:48 am MirrorX wrote:
> hello to all
>
> i would like your help in the following matter ->
>
> we have 2 identical databases. the 1st was built from scratch while the 2nd
> was 'restored' from a dump of another database (without the data). so the
> sequences for in
hello to all
i would like your help in the following matter ->
we have 2 identical databases. the 1st was built from scratch while the 2nd
was 'restored' from a dump of another database (without the data). so the
sequences for instance on the 2nd started from very big numbers. in these
databases
