From: | Scott Mead <scott(dot)lists(at)enterprisedb(dot)com> |
---|---|
To: | Jennifer Spencer <jenniferm411(at)hotmail(dot)com> |
Cc: | scott(dot)marlowe(at)gmail(dot)com, swhitney(at)journyx(dot)com, kevin(dot)grittner(at)wicourts(dot)gov, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Catching up Production from Warm Standby aftermaintenance - Please help |
Date: | 2009-07-07 17:50:40 |
Message-ID: | d3ab2ec80907071050y731b9a6fna5e0ff483528db4b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Tue, Jul 7, 2009 at 1:40 PM, Jennifer Spencer
<jenniferm411(at)hotmail(dot)com>wrote:
> You are sure that the XID wraparound is gone? That's good news. No other
> reasons for vacuum full on the entire database.
>
I think we're talking apples and gorillas on the use of the word 'full'.
There is a command:
VACUUM FULL;
When you do that, you lock a table and much hatred reigns upon you from
user-land.
When you:
vacuum all databases in a cluster (notice, no 'FULL' here), (could be
through autovacuum)
You are doing a vacuum that is capable of operating alongside
transactions.
XID wrap-around is still an issue, but if you have autovacuum on and you
pay attention to your logs, you'll be okay.
>
> We could do it a table at a time if we absolutely have to do it, and that
> would minimize down time on the rest of the system.
>
No need, see above.
Also, a quick note about your growth pattern (~ 1 TB / year)
If you're going to be growing that much, index builds on a TB of data
really stink. You may want to look into constraint_exclusion partitioning
(maybe by quarter or something easy to chunk up ) would be worth-while.
When you do need to do index rebuilds, you can:
A) Do them concurrently
Rebuilding an index becomes
CREATE INDEX CONCURRENTLY my_index_1 ....
DROP INDEX my_index_0;
ANALYZE table;
That way, you aren't blocking during that rebuild.
B) Your indexes will be a subset of your data, in my example, you'd only be
building one quarter's worth of indexes.
C) It's possible that after a quarter is over, you won't even need to
reindex because maybe you won't need data from a previous quarter.
Good - glad to be wrong about that! We do mostly inserts, no updates and
> very few deletes. We drop entire tables but don't delete often. We have
> very long rows, though. Do you think the above is a situation likely to
> create extreme bloat?
I wonder, what do you use to decide when to reindex? Under this
situation, it's very possible that you don't need to do it all that often.
Are you just flying 'willy-nilly' about reindexing things, or is there some
indicator you use?
--Scott
>
> -Jennifer
>
> > > I _think_ autovacuum, somewhere around early 8.x resolves the
> transaction
> > > wrap-around issues, but someone else should verify that.
> >
> > Ayup.
> >
> > --
> > Sent via pgsql-admin mailing list (pgsql-admin(at)postgresql(dot)org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-admin
>
> ------------------------------
> Lauren found her dream laptop. Find the PC that’s right for you.<http://www.microsoft.com/windows/choosepc/?ocid=ftp_val_wl_290>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Mead | 2009-07-07 17:51:56 | Re: Catching up Production from Warm Standbyaftermaintenance - Please help |
Previous Message | Lewis Kapell | 2009-07-07 17:46:10 | Re: Catching up Production from Warm Standbyaftermaintenance - Please help |