Horton

Re: Bugs/slowness inserting and indexing cubes

Alexander Korotkov <aekorotkov@gmail.com>

View thread
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org, Jay Levitt <jay.levitt@gmail.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2012-02-15T14:40:22Z
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. pg_dump: Further reduce reliance on global variables.

  2. Fix postmaster to attempt restart after a hot-standby crash.

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
> gistRelocateBuildBuffersOnSpli**t(), 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
> gistRelocateBuildBuffersOnSpli**t() if the page doesn't have a buffer.
> Moreover, if the page has a buffer but it's empty,
> gistRelocateBuildBuffersOnSpli**t() 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.