| From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> | 
|---|---|
| To: | Aris Samad-Yahaya <aris(at)quickschools(dot)com> | 
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org | 
| Subject: | Re: CREATE TABLE slowing down significantly over time | 
| Date: | 2009-11-08 05:30:56 | 
| Message-ID: | dcc563d10911072130i6e029e5dg815d4f7909e19383@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-performance | 
On Sat, Nov 7, 2009 at 9:58 PM, Aris Samad-Yahaya <aris(at)quickschools(dot)com> 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 performance for creating a single
> table manually improved dramatically (back to what it used to be), but as
> soon as I created the next schema, the performance went back down to the
> same level.
>
> So there's a clue there somewhere. Next I will try to vacuum full the entire
> database.
If you don't run autovac, it's possible you've managed to bloat your
pg_catalog tables...  Note that we run similar numbers of tables, as
we have 30 tables and about 10 indexes in over 2000 schemas.  We did
the trick Tom posted:
alter function pg_table_is_visible(oid) cost 10;
to get faster tab completion and / or \d performance.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2009-11-09 03:58:49 | Re: CREATE TABLE slowing down significantly over time | 
| Previous Message | Aris Samad-Yahaya | 2009-11-08 04:58:03 | Re: CREATE TABLE slowing down significantly over time |