On 28/08/06, Michal Taborsky - Internet Mall <[EMAIL PROTECTED]> wrote:
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/analyz
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
performanc
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.
On Mon, 2006-08-28 at 08:47, Guillaume Cottenceau wrote:
> Markus Schaber 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
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 t
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 actuall
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 pg_cat
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
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 thi
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
"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
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 6
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
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 fo
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 qu
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
th
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
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 ap
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
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 that and it opens
multiple connections and it exceeds 64.
Becaus
Markus Schaber 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 module at least since
Hi, Guillaume,
Guillaume Cottenceau wrote:
>> So I assume that you never UPDATE, but only INSERT new entries and
>> sometimes DELETE a big bunch of entries from the beginning.
>
> Actually, in the version of software where we have the problem,
> that's exactly the case. But in newer versions, UP
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 me
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 proba
> > 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
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
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
somet
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 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 i
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
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, recrea
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.
Sen
32 matches
Mail list logo
