From: | Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info> |
---|---|
To: | Josh Harrison <joshques(at)gmail(dot)com> |
Cc: | Trevor Talbot <quension(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: postgresql storage and performance questions |
Date: | 2007-11-20 19:13:02 |
Message-ID: | 1195585982.5362.5.camel@bnicholson-desktop |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, 2007-11-20 at 13:04 -0500, Josh Harrison wrote:
> On Nov 20, 2007 11:13 AM, Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info> wrote:
> > On Tue, 2007-11-20 at 07:22 -0500, Josh Harrison wrote:
> >
> > > There were a couple of things we noted.
> > > 1. Tablesize twice as much than oracle-- Im not sure if postgres null
> > > columns has any overhead since we have lots of null columns in our
> > > tables.Does postgresql has lots of overhead for null columns?
> >
> > Did you by any chance have an aborted load of the data? If you load in
> > a table, and that load fails or does not commit, it will still occupy
> > the space until you vacuum. If you try to load again, the table will be
> > twice the size.
> >
> > If you want to compact the physical space the table occupies, you can
> > try running VACUUM FULL on it, and possibly a redindex afterwards. This
> > will bring the physical space down to the minimum. Both of these
> > operations will lock out access to the tables though.
> I ran vacuum full on this table already. I haven't re-indexed it. But
> this will not affect the table size...right...since indexes are stored
> separately?
You are correct about the indexes.
--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.
From | Date | Subject | |
---|---|---|---|
Next Message | Vivek Khera | 2007-11-20 19:14:22 | Re: postgresql storage and performance questions |
Previous Message | Josh Harrison | 2007-11-20 18:04:48 | Re: postgresql storage and performance questions |