Horton

Re: GiST insert algorithm rewrite

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

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: 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-13T15:14:29Z
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:
> But that creates a new problem: There's a maximum of three backup blocks 
> per WAL record, but a GiST page can be split into any number of child 
> pages as one operation. You might run out of backup block slots.

> Attached is an updated patch, but that issue with limited number of 
> backup blocks needs to be resolved. The straightforward way would be to 
> change the WAL format to increase the limit.

I don't think you can fix it that way.  If a page can be split into any
number of child pages, then no fixed number of pages in a WAL record
will be enough.  Even if you were willing to suppose that ~16 would be
enough, it would be a bad idea because of the extra overhead added into
XLogInsert, which'd be paid by *every* WAL insert operation.

I think you need to refactor the operation so that there's one WAL
record per child page, or something along that line.  I concede this
might be diffcult :-(

			regards, tom lane