Re: GiST insert algorithm rewrite

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Greg Stark <gsstark@mit.edu>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>, Bruce Momjian <bruce@momjian.us>, Teodor Sigaev <teodor@sigaev.ru>, Oleg Bartunov <oleg@sai.msu.su>
Date: 2010-12-13T18:30:55Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. New feature:

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> On 13.12.2010 19:48, Tom Lane wrote:
>> Yeah.  Wouldn't the original page-split record have been carrying full
>> page images already?

> Yes.

> BTW, the original split record doesn't run into the limit because it 
> doesn't use the backup-block mechanism, it contains all the tuples for 
> all the pages in the main payload.

I see.

>> (And if so, why didn't we have this problem in the
>> previous implementation?)

> In the previous implementation, the NSN was updated immediately in the 
> page split record, and there was no follow-right flag to clear. So the 
> child pages didn't need to be updated when the downlinks are inserted.

Can we fix it so that each child page is updated, and its downlink
inserted, as a separate atomic action?  That'd require each intermediate
state to be consistent and crash-safe, but I think you really need the
intermediate states to be consistent anyway because of concurrent scans.

			regards, tom lane