Re: Status of the table access method work

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

In response to

Browse pgsql-hackers by date

  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