Horton

Re: GiST insert algorithm rewrite

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

View thread
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Teodor Sigaev <teodor@sigaev.ru>, Oleg Bartunov <oleg@sai.msu.su>
Date: 2010-11-16T18:50:49Z
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 16.11.2010 20:46, Robert Haas wrote:
> On Tue, Nov 16, 2010 at 1:22 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com>  wrote:
>> BTW, I don't try to fix incomplete splits during vacuum in the patch. That's
>> perhaps a bit surprising, and probably would be easy to add, but I left it
>> out for now as it's not strictly necessary.
>
> Seems like it would be good to have this; otherwise, the split might
> stay incompletely indefinitely?  Would that be bad?

Nothing bad should happen. Scans that need to traverse the incompletely 
split page would just be marginally slower.

> If we start to enlarge the bounding boxes on the higher levels of the
> tree and then crash before inserting the key, is there any mechanism
> for getting them back down to the minimal size?

No. There's also no mechanism for trimming the bounding boxes if a tuple 
is deleted.

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