Re: Bugs/slowness inserting and indexing cubes - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Bugs/slowness inserting and indexing cubes
Date
Msg-id CAPpHfdsncSRFYvQ3t0HVLYOvxJUbMSwOuQRRH4Eq-+p7Te=AmA@mail.gmail.com
Whole thread Raw
In response to Re: Bugs/slowness inserting and indexing cubes  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Bugs/slowness inserting and indexing cubes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Feb 15, 2012 at 4:26 PM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote:
Actually, I think it made sense to simply do nothing if the buffer doesn't exist. The algorithm doesn't require that all the buffers must exist at all times. It is quite accidental that whenever we call gistRelocateBuildBuffersOnSplit(), the page must already have its buffer created (and as we found out, the assumption doesn't hold after a root split, anyway). Also, we talked earlier that it would be good to destroy buffers that become completely empty, to save memory. If we do that, we'd have to remove that check anyway.

So, I think we should go with your original fix and simply do nothing in gistRelocateBuildBuffersOnSplit() if the page doesn't have a buffer. Moreover, if the page has a buffer but it's empty, gistRelocateBuildBuffersOnSplit() doesn't need to create buffers for the new sibling pages. In the final emptying phase, that's a waste of time, the buffers we create will never be used, and even before that I think it's better to create the buffers lazily.

I agree.

------
With best regards,
Alexander Korotkov.

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Progress on fast path sorting, btree index creation time
Next
From: Robert Haas
Date:
Subject: Re: [trivial patch] typo in doc/src/sgml/sepgsql.sgml