Horton

Re: GiST insert algorithm rewrite

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

View thread
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
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-13T17:57:52Z
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:

On 13.12.2010 19:48, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com>  writes:
>> On 13.12.2010 19:19, Greg Stark wrote:
>>> If it's only the backup blocks that matter couldn't you generate noop
>>> WAL records with just the full page image in them. Once all those are
>>> generated then generate the actual split operation and since all the
>>> pages have been written to wal since the last checkpoint they won't
>>> need any backup block slots.
>>>
>>> This would require surpressing any checkpoints between writing the
>>> first backup block and the final operation record. That might be
>>> pretty hard to do cleanly.
>
>> That would work, but it brings us back to square one
>
> 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.

>  (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.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com