Scott Marlowe wrote:
Also note that the argument that autovacuum chews up too much IO is
moot now that you can set cost delay to 10 to 20 milliseconds. Unless
you're running on the hairy edge of maximum IO at all times, autovac
should be pretty much unnoticed
And if you're running on the hairy e
On Mon, Nov 9, 2009 at 9:46 AM, Anj Adu wrote:
> Why is reindex needed ?
VACUUM FULL does not fix index bloat, only table boat.
...Robert
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
On Mon, Nov 9, 2009 at 5:22 AM, Robert Haas wrote:
> On Sat, Nov 7, 2009 at 11:58 PM, Aris Samad-Yahaya
> wrote:
>> We vacuum analyze nightly, and vacuum normally ad-hoc (but we're going to
>> schedule this weekly moving forward).
>>
>> Interesting pointer about system catalog bloat. I tried to v
Why is reindex needed ?Unless most of the key values get deleted
frequently..this is not needed. (I am assuming postgres 8.x and above)
On Sun, Nov 8, 2009 at 7:58 PM, Robert Haas wrote:
> On Sat, Nov 7, 2009 at 11:58 PM, Aris Samad-Yahaya
> wrote:
>> We vacuum analyze nightly, and vacuum no
On Sat, Nov 7, 2009 at 11:58 PM, Aris Samad-Yahaya
wrote:
> We vacuum analyze nightly, and vacuum normally ad-hoc (but we're going to
> schedule this weekly moving forward).
>
> Interesting pointer about system catalog bloat. I tried to vacuum full the
> system catalog tables (pg_*), and the perfo
On Mon, Nov 9, 2009 at 3:58 AM, Robert Haas wrote:
>
>
> And maybe REINDEX, too.
yup, nevermind the mess in table, indices are getting fscked much quicker
than table it self, because of its structure.
--
GJ
On Sat, Nov 7, 2009 at 11:58 PM, Aris Samad-Yahaya
wrote:
> We vacuum analyze nightly, and vacuum normally ad-hoc (but we're going to
> schedule this weekly moving forward).
>
> Interesting pointer about system catalog bloat. I tried to vacuum full the
> system catalog tables (pg_*), and the perfo
On Sat, Nov 7, 2009 at 9:58 PM, Aris Samad-Yahaya wrote:
> We vacuum analyze nightly, and vacuum normally ad-hoc (but we're going to
> schedule this weekly moving forward).
>
> Interesting pointer about system catalog bloat. I tried to vacuum full the
> system catalog tables (pg_*), and the perfor
: Saturday, November 07, 2009 10:29 PM
To: Aris Samad-Yahaya
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] CREATE TABLE slowing down significantly over time
"Aris Samad-Yahaya" writes:
> I'm facing a problem where running a CREATE TABLE has slowed down
> significa
ounts into separate schemas.
-Original Message-
From: Craig Ringer [mailto:cr...@postnewspapers.com.au]
Sent: Saturday, November 07, 2009 10:48 PM
To: Aris Samad-Yahaya
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] CREATE TABLE slowing down significantly over time
On 8/11/200
On 8/11/2009 11:15 AM, Aris Samad-Yahaya wrote:
> It used to take about 15 seconds to create those 300 tables in a new
> schema (when there were only a few schemas, say about 50). It now takes
> about 3 minutes (and now we have about 200 schemas, with more data but
> not hugely so).
200 schemas,
"Aris Samad-Yahaya" writes:
> I'm facing a problem where running a CREATE TABLE has slowed down
> significantly over time.
System catalog bloat maybe? What are your vacuuming practices?
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@pos
I'm facing a problem where running a CREATE TABLE has slowed down
significantly over time.
This is problematic because my application needs to routinely create a new
schema and create 300 tables in each new schema. In total it takes about 3
minutes, which may not seem like a big deal, but this
13 matches
Mail list logo
