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 →
-
New feature:
- 0ad7db4be4b1 7.1.1 cited
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