On Fri, 2010-09-03 at 11:29 -0400, Tom Lane wrote:
I'm confused. I'm still seeing a bug in here: I cannot restore a
dump
effectively... Running CLUSTER or VACUUM FULL does not make any
sense to
me in here.
Oh, wait. What you need is this patch:
2010-06-06 23:01 itagaki
snip
For
Hi,
On Fri, 2010-09-03 at 11:29 -0400, Tom Lane wrote:
I'm confused. I'm still seeing a bug in here: I cannot restore a
dump effectively... Running CLUSTER or VACUUM FULL does not make any
sense to me in here.
Oh, wait. What you need is this patch:
2010-06-06 23:01 itagaki
snip
http://www.tomtop.com/home-garden/werkzeuge/digital-scales.html Digital
Scales for any application. Wholesale digital scale pricing available.
American
http://www.tomtop.com/20g40kg-digital-hanging-luggage-fishing-weight-scale_p11432.html
Weight Scales has what you need.
--
View this message
Hi,
On Thu, 2010-09-02 at 13:22 -0400, Tom Lane wrote:
Devrim, have you identified yet which tables have the bloat? Are they
the ones with tweaked autovacuum parameters?
That's it.
On prod server, that table consumes 50 GB disk space, and on the backup
machine, it uses 148 GB. I applied
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= dev...@gunduz.org writes:
On Thu, 2010-09-02 at 13:22 -0400, Tom Lane wrote:
Devrim, have you identified yet which tables have the bloat? Are they
the ones with tweaked autovacuum parameters?
That's it.
On prod server, that table consumes 50 GB disk
On Fri, 2010-09-03 at 09:41 -0400, Tom Lane wrote:
This is 8.4.4 btw...
OK, so the bug is fixed, but you still have fillfactor = 0 on the
affected table.
I'm confused. I'm still seeing a bug in here: I cannot restore a dump
effectively... Running CLUSTER or VACUUM FULL does not make any
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= dev...@gunduz.org writes:
On Fri, 2010-09-03 at 09:41 -0400, Tom Lane wrote:
This is 8.4.4 btw...
OK, so the bug is fixed, but you still have fillfactor = 0 on the
affected table.
I'm confused. I'm still seeing a bug in here: I cannot restore a dump
Excerpts from Devrim GÜNDÜZ's message of mié sep 01 17:39:55 -0400 2010:
On Wed, 2010-09-01 at 17:32 -0400, Tom Lane wrote:
But are you sure there aren't some fillfactor tweaks in there too?
I'm sure. fillfactor related changes are on the radar, but I did not
commit them yet...
Maybe
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Devrim GÃNDÃZ's message of mié sep 01 17:39:55 -0400 2010:
On Wed, 2010-09-01 at 17:32 -0400, Tom Lane wrote:
But are you sure there aren't some fillfactor tweaks in there too?
I'm sure. fillfactor related changes are on the
On Tue, 2010-08-31 at 18:08 -0600, Scott Marlowe wrote:
ny chance you've restored to different dbs
and have two copies? Or double the data in one db?
Nope. This is a single database, and I restored only once.. # of rows in
tables match to the ones in prod...
--
Devrim GÜNDÜZ
PostgreSQL
2010/9/1 Devrim GÜNDÜZ dev...@gunduz.org:
On Tue, 2010-08-31 at 18:08 -0600, Scott Marlowe wrote:
ny chance you've restored to different dbs
and have two copies? Or double the data in one db?
Nope. This is a single database, and I restored only once.. # of rows in
tables match to the ones
On 31/08/10 22:17, Devrim GÜNDÜZ wrote:
I have seen the opposite of this tons of times before, but I haven't
seen an increase after restore before. Does anyone know what may cause
this? Where should I look at?
Could you have changed the fillfactor on some big tables/indexes in the
live
Hi,
On Wed, 2010-09-01 at 21:13 +0100, Richard Huxton wrote:
Could you have changed the fillfactor on some big tables/indexes in
the live database after populating them?
Nope. Even a pg_dump -h prod|psql backup_node resulted with the same
issue
Is the locale the same on each machine/db?
On 01/09/10 21:32, Devrim GÜNDÜZ wrote:
On Wed, 2010-09-01 at 21:13 +0100, Richard Huxton wrote:
Could you have changed the fillfactor on some big tables/indexes in
the live database after populating them?
Nope. Even a pg_dump -h prod|psql backup_node resulted with the same
issue
Is the
Excerpts from Richard Huxton's message of mié sep 01 16:39:55 -0400 2010:
OK - so not fillfactor and not some unicode-related padding. I can't see
how a 32 vs 64-bit architecture change could produce anything like a
doubling of database size.
Depending on table schemas, why not? e.g.
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Richard Huxton's message of mié sep 01 16:39:55 -0400 2010:
OK - so not fillfactor and not some unicode-related padding. I can't see
how a 32 vs 64-bit architecture change could produce anything like a
doubling of database
On Wed, 2010-09-01 at 16:50 -0400, Alvaro Herrera wrote:
Devrim didn't specify the platform on each server AFAICS.
Both are Red Hat /CentOS 5.5, x86_64, running with identical software
versions...
I first inclined to blame LVM+storage, however I could duplicate this
issue on local disks, too.
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= dev...@gunduz.org writes:
Alvaro, this may be a stupid question but: I enabled custom autovac
settings for some tables. These changes are included in the dump. May
this affect on-disk size?
Doesn't seem likely that that would matter to the state immediately
On Wed, 2010-09-01 at 17:32 -0400, Tom Lane wrote:
But are you sure there aren't some fillfactor tweaks in there too?
I'm sure. fillfactor related changes are on the radar, but I did not
commit them yet...
--
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
PostgreSQL
On Wed, 2010-09-01 at 16:59 -0400, Tom Lane wrote:
It would help if Devrim could break down the bloat to the level of
individual tables/indexes.
While setting up this data (by anonymizing table names, etc), I saw that
almost all relations are smaller on backup server, as compared to prod.
I tried to restore one of our db backups to 3 different machines today.
After restore, all machines reported larger on-disk size, and also
psql's \l+ confirmed that.
Here is the live machine:
On-disk size: 84 GB
Size reported by psql: 79 GB
Backup machine 1:
On-disk size: 162 GB
Size reported
2010/8/31 Devrim GÜNDÜZ dev...@gunduz.org:
I tried to restore one of our db backups to 3 different machines today.
After restore, all machines reported larger on-disk size, and also
psql's \l+ confirmed that.
Here is the live machine:
On-disk size: 84 GB
Size reported by psql: 79 GB
22 matches
Mail list logo
