From: | Rod Taylor <rbt(at)rbt(dot)ca> |
---|---|
To: | Dave E Martin XXIII <postgresql-to(dot)dave(at)dave(dot)to> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Index speeds up one row table (why)? |
Date: | 2003-06-01 02:29:33 |
Message-ID: | 1054434573.11968.42.camel@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-performance |
> vacuum verbose bigint_unique_ids;
> INFO: --Relation public.bigint_unique_ids--
> INFO: Index bigint_unique_ids__table_name: Pages 29; Tuples 1: Deleted
> 5354.
> CPU 0.01s/0.04u sec elapsed 0.05 sec.
> INFO: Removed 11348 tuples in 79 pages.
> CPU 0.00s/0.02u sec elapsed 0.02 sec.
> INFO: Pages 79: Changed 1, Empty 0; Tup 1: Vac 11348, Keep 0, UnUsed 0.
> Total CPU 0.03s/0.06u sec elapsed 0.14 sec.
Vacuum (regular, not full) frequently enough that the 'Pages' value
doesn't increase past 1 and you'll be fine. A sequential scan on a very
small table is what you want to have.
In this particular case, vacuum removed over 11000 dead versions of the
tuple.
An 8 k page will hold approx 140 tuples based on your structure. So,
for every ~100 updates you'll want to run vacuum (regular, not full) on
the table.
--
Rod Taylor <rbt(at)rbt(dot)ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Wolff III | 2003-06-01 05:23:51 | Re: Bug or not... |
Previous Message | Dave E Martin XXIII | 2003-05-31 23:17:38 | Re: Index speeds up one row table (why)? |
From | Date | Subject | |
---|---|---|---|
Next Message | Brian Tarbox | 2003-06-01 02:55:18 | are views typically any faster/slower than equivilent joins? |
Previous Message | Dave E Martin XXIII | 2003-05-31 22:56:56 | Re: Index speeds up one row table (why)? |