| From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
|---|---|
| To: | Leon <leon(at)udmnet(dot)ru> |
| Cc: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, David Warnock <david(at)sundayta(dot)co(dot)uk>, pgsql-general <pgsql-general(at)postgreSQL(dot)org>, PostgreSQL Developers List <hackers(at)postgreSQL(dot)org> |
| Subject: | Re: [GENERAL] Joins and links |
| Date: | 1999-07-06 02:29:52 |
| Message-ID: | 37816A20.D00AD969@krs.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
Leon wrote:
>
> Ah, you mean MVCC! That's what I replied to Tom Lane:
>
> > 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.
Old tuple version points to new version right now -:).
O how else could we handle updates in read committed mode
(new tuple version are not visible to concurrent update).
Let's go to hackers list.
But also let's relax for some more time, Leon... -:)
Vadim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Juan Grigera | 1999-07-06 02:33:50 | JoinClauseSelecivity: bad value |
| Previous Message | Bruce Momjian | 1999-07-06 01:20:34 | Re: Fw: Re[2]: [GENERAL] Joins and links |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Leon | 1999-07-06 05:46:21 | Re: [HACKERS] Fwd: Joins and links |
| Previous Message | Chris Bitmead | 1999-07-06 00:10:27 | Re: [GENERAL] Joins and links |