So, I've run a number of PG databases for a number of years.. and I've
now run into something I've never seen before in the most trivial
of places.
A couple of months back my girlfriend installed a music player called
amarok on her system... I don't know much about it, but it stores its
metada
Gregory Maxwell wrote:
> I recently noticed that this database has grown to a huge size. ...
> Which I found to be somewhat odd because none of the tables have more
> than around 1000 rows. I hadn't been vacuuming because I didn't
> think that anything would ever be deleted so I performed a
On 3/23/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Gregory Maxwell wrote:
>
> > I recently noticed that this database has grown to a huge size. ...
> > Which I found to be somewhat odd because none of the tables have more
> > than around 1000 rows. I hadn't been vacuuming because I didn't
>
"Gregory Maxwell" <[EMAIL PROTECTED]> writes:
> When I vacuum fulled nothing else was connected.. I just restarted PG
> and vacuumed again.. no obvious change of disk size (still.. 6.4
> gigs).. but this changed:
> amarokcollection=# select relname, pg_relation_size(oid) FROM
> pg_class ORDER BY
On 3/23/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> > amarokcollection=# select relname, pg_relation_size(oid) FROM
> > pg_class ORDER BY 2 DESC LIMIT 20;
> > relname | pg_relation_size
> > -+--
> > pg_attribute_relid_attnam_
"Gregory Maxwell" <[EMAIL PROTECTED]> writes:
> So it's by design that these now bloated index won't shrink if let
> unvacuumed? I didn't expect to hit something like that.
Well, the VACUUM FULL algorithm is incapable of shrinking indexes ---
the only way is REINDEX, or something else that reconst
Am Freitag, 24. März 2006 05:48 schrieb Tom Lane:
> Well, the VACUUM FULL algorithm is incapable of shrinking indexes ---
> the only way is REINDEX, or something else that reconstructs indexes
> from scratch, such as CLUSTER. One of the things we need to look into
> is putting more smarts into VAC
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 24. März 2006 05:48 schrieb Tom Lane:
>> Well, the VACUUM FULL algorithm is incapable of shrinking indexes ---
>> the only way is REINDEX, or something else that reconstructs indexes
>> from scratch, such as CLUSTER. One of the things we n
On Fri, Mar 24, 2006 at 10:02:01AM -0500, Tom Lane wrote:
> Actually, I wonder whether VACUUM FULL shouldn't be thrown away and
> replaced by something else entirely. That algorithm only really works
> nicely when just a small percentage of the rows need to be moved to
> re-compact the table --- i
Two questions in this regard please?
1) Is tuple theory not the root of this problem
2) Vacuum does much the same as a traditional database reorg, and online reorgs are a reality now
1) If I understand tuple theory correctly, copies of rows are created through normal Postgres processing, that exp
In vacuum full output, indexes are listed as having been vacuumed along with their table.
Have I misinterpreted this message saying that vacuum is incapable of vacuuming indexes (and reindex is the only option to do so) please?
On 3/25/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Peter Eisentraut <[EMA
On Fri, 2006-03-24 at 17:43, Jim C. Nasby wrote:
>
> Therein lies part of the problem: enough disk space. Now that we're
> seeing more and more use of PostgreSQL in data warehousing, it's
> becomming less safe to assume you'll have enough disk space to fix bloat
> on large tables. Plus I suspect
ilto:[EMAIL PROTECTED] On Behalf Of Rafael Martinez
Guerrero
Sent: Tuesday, 28 March, 2006 1:09 PM
To: Jim C. Nasby
Cc: Tom Lane; Peter Eisentraut; pgsql-admin@postgresql.org; Gregory Maxwell
Subject: Re: [ADMIN] Bloated pg_shdepend_depender_index
On Fri, 2006-03-24 at 17:43, Jim C. Nasby wr
On Tue, Mar 28, 2006 at 03:54:30PM +0100, Andy Shellam wrote:
> QUOTE:
> Exactly this issue and that you have to make a 'full' dump/restore
> between major release is a big minus I hear everywhere I
> explain/discuss about postgres for 24/7 and big databases.
> END QUOTE
>
On Tue, 2006-03-28 at 12:09 -0600, Jim C. Nasby wrote:
>
> Fortunately, you can use Slony to migrate between versions, greatly
> reducing downtime.
Yes, this is true, but the problem is that if the database is 'big' and
running in an expensive system you need to double your investment only
for t
On Tue, 2006-03-28 at 13:51, Rafael Martinez wrote:
> On Tue, 2006-03-28 at 12:09 -0600, Jim C. Nasby wrote:
>
> >
> > Fortunately, you can use Slony to migrate between versions, greatly
> > reducing downtime.
>
> Yes, this is true, but the problem is that if the database is 'big' and
> running
On Tue, 2006-03-28 at 15:15 -0600, Scott Marlowe wrote:
> On Tue, 2006-03-28 at 13:51, Rafael Martinez wrote:
> > On Tue, 2006-03-28 at 12:09 -0600, Jim C. Nasby wrote:
> >
> > >
> > > Fortunately, you can use Slony to migrate between versions, greatly
> > > reducing downtime.
> >
> > Yes, this
On Wed, Mar 29, 2006 at 01:05:59AM +0200, Rafael Martinez wrote:
> I work with postgresql every day and I am very happy with it, but this
> does not mean I can not see the issues that could be improve to have a
> even better open source DBMS. And I think in my humble opinion that
> bloated indexes
This is true, but you could run the new version on the same server/different
port to the current version, and do a simultaneous dump/restore without
having to use extra disk space, or taking your production database offline -
then you can schedule a time to kill the old one, re-assign the port on t
Andy Shellam wrote:
This is true, but you could run the new version on the same server/different
port to the current version, and do a simultaneous dump/restore without
having to use extra disk space, or taking your production database offline -
then you can schedule a time to kill the old one,
On Wed, 2006-03-29 at 13:16 +0100, Andy Shellam wrote:
> This is true, but you could run the new version on the same server/different
> port to the current version, and do a simultaneous dump/restore without
> having to use extra disk space, or taking your production database offline -
> then you c
On Tue, 2006-03-28 at 17:17 -0600, Jim C. Nasby wrote:
> On Wed, Mar 29, 2006 at 01:05:59AM +0200, Rafael Martinez wrote:
> > I work with postgresql every day and I am very happy with it, but this
> > does not mean I can not see the issues that could be improve to have a
> > even better open sourc
On Wed, Mar 29, 2006 at 07:19:10PM +0200, Rafael Martinez wrote:
> On Tue, 2006-03-28 at 17:17 -0600, Jim C. Nasby wrote:
> > On Wed, Mar 29, 2006 at 01:05:59AM +0200, Rafael Martinez wrote:
> > > I work with postgresql every day and I am very happy with it, but this
> > > does not mean I can not s
Please could someone help me with my questions below?
On 3/25/06, adey <[EMAIL PROTECTED]> wrote:
Two questions in this regard please?
1) Is tuple theory not the root of this problem
2) Vacuum does much the same as a traditional database reorg, and online reorgs are a reality now
1) If I unders
adey wrote:
> > 2) Can vacuum full not be redesigned to run online without locking tables
> > and users,
This is already done. See non-FULL VACUUM.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
TODO already has:
* Improve speed with indexes
For large table adjustments during VACUUM FULL, it is faster to
reindex rather than update the index.
---
Tom Lane wrote:
> Peter E
26 matches
Mail list logo
