Hello Tom,
Tuesday, July 06, 1999 you wrote:
T> Is it small?
It is :) First you should tell me what is the cost of tid lookup.
If it is significantly more expensive than C pointer, then we
should consider implementing such cheap pointer. If tid is already
cheap, then even 10 consecutive lookups will cost almost nothing.
And besides all, you should consider statistics. Can you name
five or even three applications where large databases are
massively updated without being vacuumed often?
T> After multiple updates to the referenced tuple, you'd be
T> talking about following a chain of TID references in order to find the
T> referenced tuple from the referencing tuple. I'd expect this to take
T> more time than an index access within a fairly small number of updates
T> (maybe four or so, just on the basis of counting disk-block fetches).
T> VACUUM is an interesting problem as well: to clean up the chains as you
T> suggest, VACUUM could no longer be a one-table-at-a-time proposition.
T> It would have to be able to update tuples elsewhere while repacking the
T> tuples in the current table. This probably means that VACUUM requires
T> a global lock across the whole database.
Does VACUUM require lock on the vacuumed table now? I am sure it
does. And in our case we must lock the vacuumed table and all
the tables that are referencing it, not all tables.
And, besides, manual suggests that VACUUM should be done
nightly, not daily :)
Having aquired such lock, vacuum should update the "main"
table first, then update all links in referencing tables.
It can be done using oids, which are matched in new and old
versions of "main "table (are oids preserved during vacuum? -
if they are not, this can be done with primary key)
T> Also, making those updates
T> in an already-vacuumed table without undoing its nicely vacuummed state
T> might be tricky.
I didn' get the idea of last sentence. Anyway, I am going to sleep.
See you tomorrow :)
Best regards, Leon