| From: | Scott Carey <scott(at)richrelevance(dot)com> |
|---|---|
| To: | Kyriacos Kyriacou <kyriacosk(at)prime-tel(dot)com> |
| Cc: | Andy Colson <andy(at)squeakycode(dot)net>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: MVCC performance issue |
| Date: | 2010-11-12 18:19:59 |
| Message-ID: | 12D650E7-B135-473A-952C-0A24ACE2EFD9@richrelevance.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Nov 12, 2010, at 9:13 AM, Kyriacos Kyriacou wrote:
> My suggestion had just a single difference from what currently MVCC is
> doing (btw I never said that MVCC is bad).
>
> NOW ===> on COMMIT previous version record is expired and the
> new version record (created in new dynamically allocated
> spot, as you said) is set as "active"
>
> MY ===> on COMMIT, to update new version data over the same physical
> location that initial version was
> and release the space used to keep the new version (that was
> dynamically allocated).
But what about other transactions that can still see the old version?
You can't overwrite the old data if there are any other transactions open in the system at all. You have to have a mechanism to keep the old copy around for a while.
>
> The rest are all the same! I do not think that this is breaking anything
> and I still believe that this might help.
>
> I will try to plan upgrade the soonest possible to the newest version.
> Reading few words about HOT updates
> it seems that more or less is similar to what I have described and will
> be very helpful.
>
> Kyriacos
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-11-12 18:57:38 | Re: anti-join chosen even when slower than old plan |
| Previous Message | Scott Carey | 2010-11-12 18:13:23 | Re: MVCC performance issue |