Re: How to make lazy VACUUM of one table run in several

On E, 2005-05-02 at 10:38 -0400, Tom Lane wrote:

But what about my question about just changing xid in PGPROC ?

> Hannu Krosing <hannu(at)tm(dot)ee> writes:
> > A more general solution to the problem "VACUUM does not clean dead
> > tuples fast enough due to an old transaction" problem is keeping the
> > OldestXmin for each table separately as a list of table OIDs in each
> > PGPROC.
>
> > This would be automatically extandable to long COPY, or in fact any
> > single SQL statement running in its implicit transaction by examining
> > the query plan and reserving all tables touched by the query and its
> > dependencies.
>
> This is completely unworkable, since it amounts to assuming you know at
> the start of a serializable transaction which tables it will touch.

I meant it for "simple" things, like VACUUM and maybe also simple COPY
(tables ref'd by foreign keys can be found from pg_depend), but yes we
can't automatically know it in general case.

That's why I proposed it to be an error for any transaction with such
list to touch any tables not in the list, so the assumptions of what
tables are tested are simple to test.

> In
> point of fact you can't even know that for the current query let alone
> future ones --- consider user-defined functions.
>
> (Not to mention that we can't expect to fit that much info into a fixed
> amount of shared memory.)

what should be in shared memory, is one list of ints per backend (oids
of tables for current transaction), mostly just one :)

The general case should be not to have such list at all which assumes
that any table could be touched.

--
Hannu Krosing <hannu(at)tm(dot)ee>