On Apr 1, 2010, at 1:42 PM, Tom Lane wrote:
> Scott Carey writes:
>> Still off topic:
>
>> Will CLUSTER/VF respect FILLFACTOR in 9.0?
>
>> As far as I can tell in 8.4, it does not.
>
> Works for me, in both branches.
>
I stand corrected. I must have done something wrong in my test. On a
Scott Carey writes:
> Still off topic:
> Will CLUSTER/VF respect FILLFACTOR in 9.0?
> As far as I can tell in 8.4, it does not.
Works for me, in both branches.
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make chan
On Mar 31, 2010, at 1:47 PM, Robert Haas wrote:
> On Wed, Mar 31, 2010 at 4:37 PM, Scott Carey wrote:
>> On Mar 27, 2010, at 6:35 AM, Andy Colson wrote:
>>>
>>> Dont "VACUUM FULL", its not helping you, and is being removed in newer
>>> versions.
>>>
>>
>> Off topic: How is that going to wor
Scott Carey wrote:
>
> On Mar 27, 2010, at 6:35 AM, Andy Colson wrote:
> >
> > Dont "VACUUM FULL", its not helping you, and is being removed in newer
> > versions.
> >
>
> Off topic: How is that going to work? CLUSTER doesn't work on tables
> without an index. I would love to be able to CLU
On Wed, Mar 31, 2010 at 4:37 PM, Scott Carey wrote:
> On Mar 27, 2010, at 6:35 AM, Andy Colson wrote:
>>
>> Dont "VACUUM FULL", its not helping you, and is being removed in newer
>> versions.
>>
>
> Off topic: How is that going to work? CLUSTER doesn't work on tables
> without an index. I wou
On Mar 27, 2010, at 6:35 AM, Andy Colson wrote:
>
> Dont "VACUUM FULL", its not helping you, and is being removed in newer
> versions.
>
Off topic: How is that going to work? CLUSTER doesn't work on tables without
an index. I would love to be able to CLUSTER on some column set that doesn't
Please don't cc two of the lists here. It makes things difficult for
users who only subscribe to one list or the other who reply--their post
to the other list will be held for moderation. And that's a pain for
the moderators too. In this case, either the pgsql-admin or
pgsql-performance list
On 3/30/2010 6:17 AM, Gnanakumar wrote:
We're using pgpool-II version 2.0.1 for PostgreSQL connection management.
pgpool configurations are:
num_init_children = 450
child_life_time = 300
connection_life_time = 120
child_max_connections = 30
As you recommended, I ran "ps -ax|grep postgres" at al
Saturday, March 27, 2010 7:06 PM
To: Gnanakumar; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Database size growing over time and leads to
performance impact
On 03/27/2010 08:00 AM, Gnanakumar wrote:
> Hi,
>
> We're using PostgreSQL 8.2. Recently, in our production database, ther
Pierre C wrote:
If you realize you got a bloat problem, for instance due to a
misconfigured vacuum, use CLUSTER, which re-generates table AND index
data, and besides, having your table clustered on an index of your
choice can boost performance quite a lot in some circumstances.
8.2 is so old
1. VACUUM FULL ANALYZE once in a week during low-usage time and
VACUUM FULL compacts tables, but tends to bloat indexes. Running it weekly
is NOT RECOMMENDED.
A correctly configured autovacuum (or manual vacuum in some circumstances)
should maintain your DB healthy and you shouldn't ne
On 03/27/2010 08:00 AM, Gnanakumar wrote:
Hi,
We're using PostgreSQL 8.2. Recently, in our production database, there
was a severe performance impact.. Even though, we're regularly doing both:
1. VACUUM FULL ANALYZE once in a week during low-usage time and
2. ANALYZE everyday at low-usage time
Hi,
We're using PostgreSQL 8.2. Recently, in our production database, there was
a severe performance impact.. Even though, we're regularly doing both:
1. VACUUM FULL ANALYZE once in a week during low-usage time and
2. ANALYZE everyday at low-usage time
Also, we noticed that the
13 matches
Mail list logo
