From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Leon <leon(at)udmnet(dot)ru> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Re[4]: [HACKERS] Fwd: Joins and links |
Date: | 1999-07-05 20:33:04 |
Message-ID: | 22190.931206784@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Leon <leon(at)udmnet(dot)ru> writes:
> This problem can be solved. An offhand solution is to have
> an additional system field which will point to new tuple left after
> update. It is filled at the same time as the original tuple is
> marked invalid. So the scenario is as follows: we follow the link,
> and if we find that in the tuple where we arrived this system field
> is not NULL, we go to (the same table of course) where it is pointing
> to. Sure VACUUM will eliminate these. Performance penalty is small.
Is it small? After multiple updates to the referenced tuple, you'd be
talking about following a chain of TID references in order to find the
referenced tuple from the referencing tuple. I'd expect this to take
more time than an index access within a fairly small number of updates
(maybe four or so, just on the basis of counting disk-block fetches).
VACUUM is an interesting problem as well: to clean up the chains as you
suggest, VACUUM could no longer be a one-table-at-a-time proposition.
It would have to be able to update tuples elsewhere while repacking the
tuples in the current table. This probably means that VACUUM requires
a global lock across the whole database. Also, making those updates
in an already-vacuumed table without undoing its nicely vacuummed state
might be tricky.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Leon | 1999-07-05 21:13:09 | Re[6]: [HACKERS] Fwd: Joins and links |
Previous Message | Leon | 1999-07-05 19:46:17 | Re[2]: [HACKERS] Fwd: Joins and links |