At 02:07 PM 18/12/2002 +0100, Roel Rozendaal - IC&S wrote:
postgresql is version 7.2.
There have also been several improvements & bug fixes in PG since 7.2; you
might consider upgrading to 7.3 or 7.3.1.
Philip Warner
At 03:11 PM 18/12/2002 +0100, Roel Rozendaal - IC&S wrote:
At 12:47 PM 18/12/2002 +0100, Roel Rozendaal - IC&S wrote:
pg_toast_10945937| 3841293
It is the messageblks table. However, the query
select sum(blocksize) from messageblks;
(which should return the amount of actual data in
Philip Warner heeft op woensdag, 18 dec 2002 om 13:05
(Europe/Amsterdam) het volgende geschreven:
At 12:47 PM 18/12/2002 +0100, Roel Rozendaal - IC&S wrote:
pg_toast_10945937| 3841293
...
What exactly is this pg_toast thing?
When a text field is too large to fit on a page, it
At 02:07 PM 18/12/2002 +0100, Roel Rozendaal - IC&S wrote:
What MAX_FSM_* settings do you recommend?
I need to see the output of a VACUUM VERBOSE to know a good answer.
Otherwise, if you can give me an upper limit on the volume of mail received
each day, we could probably go with that. eg. if
At 01:00 PM 18/12/2002 +0100, Roel Rozendaal - IC&S wrote:
it got me a value of 38; the system has default config of
max_fsm_relations (100) so that shouldn't be the problem either.
A simple (heavy-handed) approach would be:
set max_fsm_relations to 1000
set vacuum frequency to daily
The only other database is template0, which gives a value of 30 for the
query; the OS is linux 2.4.5, postgresql is version 7.2.
What MAX_FSM_* settings do you recommend?
Philip Warner heeft op woensdag, 18 dec 2002 om 13:14
(Europe/Amsterdam) het volgende geschreven:
At 01:00 PM 18/12/2002
At 01:00 PM 18/12/2002 +0100, Roel Rozendaal - IC&S wrote:
it got me a value of 38; the system has default config of
max_fsm_relations (100) so that shouldn't be the problem either.
Be careful with this. You need to do this for each database (except
template0). Try '\l' in psql to get a lict o
At 12:47 PM 18/12/2002 +0100, Roel Rozendaal - IC&S wrote:
pg_toast_10945937| 3841293
...
What exactly is this pg_toast thing?
When a text field is too large to fit on a page, it is written to a
separate table (one for each real table) in chunks. My guess is that if you do:
hi philip,
I just checked your link and executed the query
select count(*) from pg_class where relkind in ('t','r');
it got me a value of 38; the system has default config of
max_fsm_relations (100) so that shouldn't be the problem either.
regards roel
Philip Warner heeft op woensdag, 18 d
Hi Philip, Steve,
The pg_largeobject table is empty, so probably it does not concern
orphaned BLOB's. The "select relname, relpages from pg_class order by
relpages desc" shows:
relname | relpages
-+--
pg_toast_10945937
At 11:23 AM 18/12/2002 +0100, Roel Rozendaal - IC&S wrote:
The problem is that postgresql keeps on eating disk space
Have a look at this link:
http://www.rhyme.com.au/manuals/pgsql-7.3/postmaster-tuning-software.html
it is an addition to the PG docs that I wrote recently and which has not
Hello Roel,
Wednesday, December 18, 2002, 7:23:49 AM, you wrote:
RRIS> Hi all,
RRIS> on of our dbmail-using customers runs a postgresql database containing
RRIS> about 10GB of data; there are ~23000 accounts, 5000 of them are being
RRIS> accessed regularly. The database is not growing (only PO
Hi all,
on of our dbmail-using customers runs a postgresql database containing
about 10GB of data; there are ~23000 accounts, 5000 of them are being
accessed regularly. The database is not growing (only POP is run),
about 2 messages are delivered each day.
The problem is that postgresql
13 matches
Mail list logo
