Andy,
For detailed instructions:
http://webmail.postgresql.org/cgi-bin/mj_wwwusr/domain=postgresql.org
regards
steve boyle
- Original Message -
From:
Andy Gussie
To: [EMAIL PROTECTED]
Sent: Tuesday, January 15, 2002 4:24
AM
Subject: [ADMIN] How do I get off
Hi all,
First of all, I apologize for all these questions but my dba knowledges
are quite grounded :(
I would like to know if there is a reveipe, good RTFM, any thing else
to estimate/evaluate values for mem_sort and shared buffers.
Thank you.
--
Jean-Christophe ARNU
s/w
Jean-Christophe ARNU wrote:
> Hi all,
> First of all, I apologize for all these questions but my dba knowledges
> are quite grounded :(
>
> I would like to know if there is a reveipe, good RTFM, any thing else
> to estimate/evaluate values for mem_sort and shared buffers.
See my hard
pgman wrote:
> Jean-Christophe ARNU wrote:
> > Hi all,
> > First of all, I apologize for all these questions but my dba knowledges
> > are quite grounded :(
> >
> > I would like to know if there is a reveipe, good RTFM, any thing else
> > to estimate/evaluate values for mem_sort and share
Hello !
I'm trying to dump postgresql 7.1.3 database and restore it in 7.2b4.
Databases are located
on different hosts. The problem is that when I run command
pg_dump databasename --verbose -b -Ft -h otherhost | pg_restore -d
databasename
after some tables are copied error occures
pg_d
On Tuesday, January 15, 2002, at 07:08 PM, Roman Gavrilov wrote:
David Stanaway wrote:
On Wednesday, January 9, 2002, at 10:31 PM, Roman Gavrilov wrote:
One more question is how can I see all tables in the template1 ?
Thanks allot.
in the psql client: psql template1
\dt
\h is definat
Our database has about 70 tables. Only a half-dozen or so have more
than 100K rows, and all of these change (99% inserts, 10K-50K rows)
during an average day.
VACUUM ANALYZE takes over an hour, and it's edging up by a couple
minutes per day.
Is there a way to look at the DEBUG stats from the VA
[EMAIL PROTECTED] (Jeff Boes) writes:
> Our database has about 70 tables. Only a half-dozen or so have more
> than 100K rows, and all of these change (99% inserts, 10K-50K rows)
> during an average day.
> VACUUM ANALYZE takes over an hour, and it's edging up by a couple
> minutes per day.
Care
Hello there
In my current project, we have postgres 7.0.x running for half a year now.
In the db, there is one table that causes problems.
This table has 66 columns and 1700 rows. SQL select's are 8 times slower
than normal when the problem starts. Is there a way to see why the
performance ist ge
