| From: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Cc: | Csaba Nagy <nagy(at)ecircle-ag(dot)com>, Chris Browne <cbbrowne(at)acm(dot)org> |
| Subject: | Re: Alternative for vacuuming queue-like tables |
| Date: | 2006-04-28 17:52:14 |
| Message-ID: | 200604281352.14380.xzilla@users.sourceforge.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Friday 28 April 2006 12:20, Csaba Nagy wrote:
> > There is, I believe, a problem there; there is a scenario where data
> > can get "dropped out from under" those old connections.
> >
> > This has been added to the TODO...
> >
> > http://www.postgresql.org/docs/faqs.TODO.html
> >
> > * Make CLUSTER preserve recently-dead tuples per MVCC requirements
>
> OK, I can see this being a problem in the general case.
>
> However, for my queue table the current behavior is a life-saver. Would
> it be possible to still provide a variant of rebuild which is documented
> to not be MVCC compliant ? Something like: I don't care the old
> transactions which did not touch yet this table to see the old data for
> this table, I want to rebuild it.
>
> I actually don't care about clustering in this case, only about
> rebuilding the table once I can get an exclusive lock on it. I guess
> this would be possible with the "switch to a copy" method except the new
> table is a different entity (as mentioned in another post) and it will
> not preserve the dependencies of the original table.
>
> I guess what I'm asking for is a kind of "REBUILD TABLE" which is not
> MVCC by definition but it would be useful in the mentioned queue table
> case.
>
vaccum full ?
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Don Walker | 2006-04-28 19:11:09 | Use of ISpell dictionaries with tsearch2 - what is the point? |
| Previous Message | Mark Harrison | 2006-04-28 17:29:58 | Re: query that needs two nested queries, is this the best |