Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Am I right in thinking that vacuum does at least two passes: one
> front-to-back to find removable tuples, and other back-to-front for
> movement?
VACUUM FULL, yes. VACUUM only does the first one.
> I know maintenance_work_mem is used for storing TIDs
On Tue, Apr 19, 2005 at 10:06:40AM -0400, Tom Lane wrote:
> BTW, VACUUM FULL does the data movement back-to-front, and stops as soon
> as it finds a tuple it cannot move down; which is a reasonable strategy
> since the goal is merely to make the file shorter. But it's entirely
> likely that there
Josh Berkus writes:
>> Not at all. What it says is that you expect 100% of the pages to have
>> useful amounts of free space, which is a *much* weaker criterion.
> H actually, it seems like, if you are vacuuming regularly, you only
> *do* need to track pages that have been touched by D
Tom,
> Not at all. What it says is that you expect 100% of the pages to have
> useful amounts of free space, which is a *much* weaker criterion.
Hmmm. Good point.
This seems to be another instance where my rule-of-thumb was based on false
logic but nevertheless arrived at correct numbers.
Josh Berkus writes:
>> select count(1), sum(relpages) from pg_class where relkind in
>> ('r','i','t')
> Well, if you do that for all databases in the cluster, it's the number you
> start with. However, setting FSM_pages to that would be assuming that you
> excpected 100% of the rows to be repl
Tambet,
> Hmm, thanks for a tip. BTW, is output of
>
> select count(1), sum(relpages) from pg_class where relkind in
> ('r','i','t')
Well, if you do that for all databases in the cluster, it's the number you
start with. However, setting FSM_pages to that would be assuming that you
excpected 10
"Tambet Matiisen" <[EMAIL PROTECTED]> writes:
> Is my current understanding correct:
> 1) VACUUM defragments each page locally - moves free space to the end of
> page.
> 2) VACUUM FULL defragments table globally - tries to fill up all
> partially free pages and deletes all resulting empty pages.
>
> Josh Berkus writes:
> >> 1) When is it necessary to run REINDEX or drop/create
> >> an index? All I could really find in the docs is:
>
> > If you need to VACUUM FULL, you need to REINDEX as well.
> For example,
> > if you drop millions of rows from a table.
>
> That's probably a prett
Josh Berkus writes:
>> 1) When is it necessary to run REINDEX or drop/create
>> an index? All I could really find in the docs is:
> If you need to VACUUM FULL, you need to REINDEX as well. For example, if you
> drop millions of rows from a table.
That's probably a pretty good rule of thumb. I
On Mon, Apr 18, 2005 at 12:21:42 -0700,
Bill Chandler <[EMAIL PROTECTED]> wrote:
>
> Running PostgreSQL 7.4.2 on Solaris.
>
> 1) When is it necessary to run REINDEX or drop/create
> an index? All I could really find in the docs is:
>
> "In some situations it is worthwhile to rebuild
> indexes
Bill,
> 1) When is it necessary to run REINDEX or drop/create
> an index? All I could really find in the docs is:
If you need to VACUUM FULL, you need to REINDEX as well. For example, if you
drop millions of rows from a table.
> 2) If reindexing is necessary, how can this be done in
> a non-o
All,
A couple of questions regarding REINDEX command:
Running PostgreSQL 7.4.2 on Solaris.
1) When is it necessary to run REINDEX or drop/create
an index? All I could really find in the docs is:
"In some situations it is worthwhile to rebuild
indexes periodically with the REINDEX command. (The
12 matches
Mail list logo
