hai admin,
un subscribe my account from list,i don't want any mails
_
Download ringtones, logos and picture messages from MSN Malaysia
http://www.msn.com.my/mobile/ringtones/default.asp
---(end of broadcas
Tom Lane wrote:
Jeff <[EMAIL PROTECTED]> writes:
given that template0 and 1 rarely change.. I don't see why we'd need to
vacuum them
You have to vacuum template1 periodically if you want pg_clog to shrink.
WOW, I saved 200 MB in one shoot vacuuming template 1 !
I learned this after 2 years of p
I'm running 7.3, and I recently observed something rather disconcerting,
using EXPLAIN ANALYZE.
If I have an index on an int8 column, and I run a query such as
SELECT * FROM [tablename] WHERE [colname] = 12345
the index is NOT used, and a sequential scan of the 200K rows is done,
taking ~ 175
Greg Stark <[EMAIL PROTECTED]> writes:
> This still suffers from one major deficiency. The order that objects are
> outputed isn't necessarily consistent between databases. If I add tables to
> the development server but then add them to the production server in a
> different order the schema still
DHS Webmaster <[EMAIL PROTECTED]> writes:
> 1. Should we be doing a periodic vacuum on template1?
Yes.
> 3. It is safe to delete all the clog files prior to the last restart of
> postgres, yes?
NO. That WILL destroy your database. Much safer to let VACUUM do
it for you.
Jeff <[EMAIL PROTECTED]> writes:
> given that template0 and 1 rarely change.. I don't see why we'd need to
> vacuum them
You have to vacuum template1 periodically if you want pg_clog to shrink.
You may know that you've never changed it, but the VACUUM code doesn't
know that.
template0 need not ge
Well, you know, I looked at the list and saw only template0, template1 &
our working DB. So just for kicks I vacuumed template1. That cleared the
directory. To my knowledge we did not modify template1 one when we setup
the database initially, so perhaps it just needed a vacuum to set the
stage corr
On Wed, 29 Oct 2003 11:53:38 -0500
DHS Webmaster <[EMAIL PROTECTED]> wrote:
> We vacuum our working database nightly. Although this is not a 'full',
> we don't exclude any tables. We don't do anything with template1
> (knowingly), so we do not perform any maintenance on it either.
Why not go thro
This thread caught my eye and I decided to look at our pg_clog
directory. Sure enough we have got every clog file since we upgraded
back in April, - 02F8.
We vacuum our working database nightly. Although this is not a 'full',
we don't exclude any tables. We don't do anything with template1
(kn
On Wed, 29 Oct 2003 11:32:12 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> Jeff <[EMAIL PROTECTED]> writes:
> > [ pg_clog not getting truncated ]
>
> pg_clog is truncated on the basis of the oldest completely vacuumed
> database in your installation. Most likely your maintenance script
> is failin
Jeff <[EMAIL PROTECTED]> writes:
> [ pg_clog not getting truncated ]
pg_clog is truncated on the basis of the oldest completely vacuumed
database in your installation. Most likely your maintenance script
is failing to vacuum some database(s) (template1, perhaps?) and/or
is doing table-by-table va
I have a machine that typically runs good, but more and more recently
when vacuum runs everything (not just pg) comes to a griding halt. If
iostat is to be believed, there isn't too much IO going on - 300kB/sec
write, 0kB read.
Now before we diagnose this as "bah!" I noticed something odd - in
Thanks guys,
I had a feeling this was the case, but wasn't sure.
The one-version pg_dump looks like a winner.
Regards
Stefan
##START##
=> Rod Taylor <[EMAIL PROTECTED]> writes:
=> >> What I did next, is put a trigger on pg_attribute that should, in theory,
=> >> on insert and update, fire up a f
Rod Taylor <[EMAIL PROTECTED]> writes:
>> What I did next, is put a trigger on pg_attribute that should, in theory,
>> on insert and update, fire up a function that will increment a version
> System tables do not use the same process for row insertion / updates as
> the rest of the system. You're
Correction on the function :
The function currently on the database did has
select int4(description) + 1 into v_new_version from pg_description
where objoid = NEW.attrelid;
in stead of
select int4(description) into v_new_version from pg_description
where objoid = NEW
Hi all,
I'm trying to create some kind of table version control
system for approximately 300 postgres databases
ranging in version from 7.1.2 to 7.3.4.
I compared the "pg_dump -s" output between
the various versions of databases, but the format is inconsistent,
and I can't do diff's to check th
16 matches
Mail list logo
