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
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 i
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
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= 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
> effectivel
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?= 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 space, and on t
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 cu
Alvaro Herrera 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 radar, but I did
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
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.
Yea
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
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= 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
after restoring;
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. T
Alvaro Herrera 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 size.
> Depending on ta
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. con
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 lo
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 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 databas
2010/9/1 Devrim GÜNDÜZ :
> 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...
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 Danı
2010/8/31 Devrim GÜNDÜZ :
>
> 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 mac
21 matches
Mail list logo
