I would like to talk to one of the org member in postgre about this issue.
This is critical for us. Please help.
It will be great, if you could provide your contact number to discuss on
this.
Thank you in advance.
Regards, Ravi
-Original Message-
From: Ravindran G - TLS, Chennai.
Hi,
We noticed a slowdown on our application while traffic was kinda
heavy. The logics after reading the docs commanded us to trim the
enlarged tables, run VACUUM ANALYZE and then expect fast
performance again; but it wasn't the case[1].
Out of the blue, we dumped the database, removed it,
Hi, Guillaume
Guillaume Cottenceau wrote:
We noticed a slowdown on our application while traffic was kinda
heavy. The logics after reading the docs commanded us to trim the
enlarged tables, run VACUUM ANALYZE and then expect fast
performance again; but it wasn't the case[1].
What exactly do
Hi Markus,
Thanks for your message.
Guillaume Cottenceau wrote:
We noticed a slowdown on our application while traffic was kinda
heavy. The logics after reading the docs commanded us to trim the
enlarged tables, run VACUUM ANALYZE and then expect fast
performance again; but it wasn't
Guillaume,
On 28 Aug 2006 11:43:16 +0200, Guillaume Cottenceau [EMAIL PROTECTED] wrote:
max_fsm_pages is 2
max_fsm_relations is 1000
Do they look low?
Yes they are probably too low if you don't run VACUUM on a regular
basis and you have a lot of UPDATE/DELETE activity. FSM doesn't take
Hi, Guillaume,
Guillaume Cottenceau wrote:
We have a couple of logs files which get larger over time
(millions of rows). As they are log files, they can be trimmed
from older values.
Ah, ok, you DELETEd the old rows.
So I assume that you never UPDATE, but only INSERT new entries and
Guillaume,
Thanks for your help.
On 28 Aug 2006 11:43:16 +0200, Guillaume Cottenceau [EMAIL PROTECTED] wrote:
max_fsm_pages is 2
max_fsm_relations is 1000
Do they look low?
Yes they are probably too low if you don't run VACUUM on a regular
basis and you have a lot of
We have a couple of logs files which get larger over time
(millions of rows). As they are log files, they can be trimmed
from older values.
Ah, ok, you DELETEd the old rows.
Yes.
So I assume that you never UPDATE, but only INSERT new entries and
sometimes DELETE a big bunch of
Hi, Guillaume,
Guillaume Cottenceau wrote:
About REINDEX: is it ok to consider that REINDEX is to indexes
what VACUUM FULL is to table data, because it cleans up unused
index pages?
Yes, roughly speaking.
And AFAICS you're not running it on a regular basis so your database
was probably
Ravindran G - TLS, Chennai. wrote:
I would like to talk to one of the org member in postgre about this issue.
This is critical for us. Please help.
It will be great, if you could provide your contact number to discuss on
this.
Sure, we're happy to help. You can contact several org members
Markus Schaber schabi 'at' logix-tt.com writes:
VACUUM ANALYZE is normally run overnight (each night). Is it not
regular enough? There can be hundreds of thousands of statements
a day.
Which PostgreSQL version are you using? Maybe you should consider
autovacuum (which is a contrib
On 8/28/06, Ravindran G - TLS, Chennai. [EMAIL PROTECTED] wrote:
Thanks Alvaro.
We are using PostgreSQL 7.1 cygwin installed on Windows 2000.
We understand that the maximum connections that can be set is 64 in
Postgresql 7.1 version.
But our application is installed in 8 / 10 PC or more than
am Mon, dem 28.08.2006, um 19:30:44 +0530 mailte Ravindran G - TLS, Chennai.
folgendes:
Thanks Alvaro.
We are using PostgreSQL 7.1 cygwin installed on Windows 2000.
*grrr*
We understand that the maximum connections that can be set is 64 in
Postgresql 7.1 version.
But our
Ravindran G - TLS, Chennai. wrote:
Thanks Alvaro.
We are using PostgreSQL 7.1 cygwin installed on Windows 2000.
We understand that the maximum connections that can be set is 64 in
Postgresql 7.1 version.
This is because of Cygwin limitations.
But our application is installed in 8 / 10
On 8/28/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
Please advise us on how to resolve this ?.
There's no solution short of upgrading.
That's a little too negative. There is at least one alternative,
possibly two...
1. Migrate the database to a Unix platform that does not suffer from
the
I just put together a view, which helps us in indentifying which
database tables are suffering from space bloat, ie. they take up much
more space than they actually should. I though this might be useful for
some folk here, because the questions about bloat-related performance
degradation are
On Mon, 2006-08-28 at 16:39 +0200, Michal Taborsky - Internet Mall
wrote:
I just put together a view, which helps us in indentifying which
database tables are suffering from space bloat, ie. they take up much
more space than they actually should. I though this might be useful for
some folk
On Mon, 2006-08-28 at 09:00, Ravindran G - TLS, Chennai. wrote:
Thanks Alvaro.
We are using PostgreSQL 7.1 cygwin installed on Windows 2000.
We understand that the maximum connections that can be set is 64 in
Postgresql 7.1 version.
But our application is installed in 8 / 10 PC or
Ravindran G - TLS, Chennai. wrote:
Hi,
We are using PostgreSQL 7.1 cygwin installed on Windows 2000 (2 GB Memory,
P4).
I would strongly suggest moving to native 8.1 :). You will find your
life much better.
Joshua D. Drake
We understand that the maximum connections that can be set is
Christopher Browne [EMAIL PROTECTED] writes:
On 8/28/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
There's no solution short of upgrading.
That's a little too negative. There is at least one alternative,
possibly two...
But both of those would probably involve work comparable to an upgrade.
Brad Nicholson napsal(a):
I just put together a view, which helps us in indentifying which
database tables are suffering from space bloat, ie. they take up much
Are you sure you haven't reinvented the wheel? Have you checked out
contrib/pgstattuple ?
Well, I wasn't aware of it, so I guess
Brad Nicholson wrote:
On Mon, 2006-08-28 at 16:39 +0200, Michal Taborsky - Internet Mall
wrote:
I just put together a view, which helps us in indentifying which
database tables are suffering from space bloat, ie. they take up much
more space than they actually should. I though this might
Hi, Michal,
Michal Taborsky - Internet Mall wrote:
When using this view, you are interested in tables, which have the
bloat column higher that say 2.0 (in freshly dump/restored/analyzed
database they should all be around 1.0).
I just noticed some columns in pg_catalog with a bloat value 1
Markus Schaber napsal(a):
Hi, Michal,
Michal Taborsky - Internet Mall wrote:
When using this view, you are interested in tables, which have the
bloat column higher that say 2.0 (in freshly dump/restored/analyzed
database they should all be around 1.0).
I just noticed some columns in
On Sun, 2006-08-27 at 21:26, Merlin Moncure wrote:
I'll be throwing in some quick stats on the box described above later
today... At first glance, the 3Ware controller is really looking like an
excellent value.
they are pretty decent. the benchmark is software raid which actually
On 8/28/06, Tom Lane [EMAIL PROTECTED] wrote:
Christopher Browne [EMAIL PROTECTED] writes:
On 8/28/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
There's no solution short of upgrading.
That's a little too negative. There is at least one alternative,
possibly two...
But both of those would
On 8/28/06, Christopher Browne [EMAIL PROTECTED] wrote:
On 8/28/06, Tom Lane [EMAIL PROTECTED] wrote:
Christopher Browne [EMAIL PROTECTED] writes:
On 8/28/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
There's no solution short of upgrading.
That's a little too negative. There is at least
Hi everyone,
We have a postgresql 8.1 installed on Solaris 10. It is running fine.
However, for the past couple days, we have seen the i/o reports
indicating that the i/o is busy most of the time. Before this, we only
saw i/o being busy occasionally (very rare). So far, there has been no
28 matches
Mail list logo
