From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Status of the table access method work |
Date: | 2019-04-18 06:27:06 |
Message-ID: | CANP8+jJ5_7C2nd9nD5Zz74EeyND+0EMX1S27eAAyK=Djw2vgGg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 10 Apr 2019 at 18:14, Alexander Korotkov <aekorotkov(at)gmail(dot)com>
wrote:
> Alternative idea is to have MVCC-aware indexes. This approach looks
> more attractive for me. In this approach you basically need xmin,
> xmax fields in index tuples. On insertion of index tuple you fill
> it's xmin. On update, previous index tuple is marked with xmax.
>
+1
xmax can be provided through to index by indexam when 1) we mark killed
tuples, 2) when we do indexscan of index entry without xmax set.
xmax can be set as a hint on normal scans, or set as part of an update, as
the index chooses
After that outdated index tuples might be deleted in the lazy manner
> when page space is required.
That is already done, so hardly any change there.
Also, we can
have special bit for "all visible" index tuples. With "all visible"
bit set this tuple can get rid of visibility fields. We can do this
for index tuples, because if index tuple requires extra space we can
split the page, in spite of heap where tuples are fixed in pages and
xmax needs to be updated in-place.
Keeping the xmin/xmax would also be useful for historical indexes, i.e.
indexes that can be used to search for data with historic snapshots.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Sergei Kornilov | 2019-04-18 06:42:41 | Re: bgwriter_lru_maxpages limits in PG 10 sample conf |
Previous Message | Masahiko Sawada | 2019-04-18 06:12:38 | Re: New vacuum option to do only freezing |